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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 16 Sep 2021 01:50:18 +0900

Hi Tom,
Here is the revision to reflect your comments on the Consumer-Facing
Interface Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-15

Also, here is the revision for synchronization with the other data model
I-Ds on the
Registration Interface Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-12

I attach the revision letters.

Thanks.

Best Regards,
Paul and Patrick

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

> 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
>
> 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
>
> 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/
>
>
> _______________________________________________
> 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: tom petch <[email-masked]>
Date: Fri, 24 Sep 2021 11:48:46 +0000

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: 15 September 2021 17:50

Hi Tom,
Here is the revision to reflect your comments on the Consumer-Facing Interface Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-15

Also, here is the revision for synchronization with the other data model I-Ds on the
Registration Interface Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-12

<tp>
I like the new names for transport and application!

Two references need adding to the I-D as they are in the YANG module
RFC4960
RFC8335

I notice that the modelling of action is different compared to nsf-facing.  This may be deliberate in which case no problem but here log-action is not derived from action whereas in nsf-facing it is.  I realise that this has primary and secondary action which nsf-facing does not.

grouping location group
a similar model in capability has a reference to RFC8805 - would that help here?

container period
 when frequency != 'only-once'
would seem to exclude start-time and end-time but the description of 
enum only-once
talks of start-time and end-time which seems a contradiction

leaf packet-rate-threshold
leaf byte-rate-threshold
could do with units; I notice that the rule name in the example is packets per second.
  Is uint32 enough for bytes per second? May be.

Tom Petch

Thanks.

Best Regards,
Paul and Patrick

On Tue, Aug 31, 2021 at 7:45 PM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[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

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]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
From: I2nsf <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> on behalf of [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[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.

Tom Petch

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:

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

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