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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 28 Oct 2021 08:33:03 +0900

Hi Tom,
I will address your further comments on the Consumer-Facing Interface Data
Model.

Thanks.

Best Regards,
Paul

2021년 9월 24일 (금) 오후 8:48, tom petch <[email-masked]>님이 작성:

> 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
>
> I attach the revision letters.
>
> <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
>
> 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]><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.
>
> 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]><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
>
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department Head
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>