From nobody Thu Aug 1 01:15:34 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE16F12007C; Thu, 1 Aug 2019 01:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAWLF9vsMKyI; Thu, 1 Aug 2019 01:15:17 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B6A12001B; Thu, 1 Aug 2019 01:15:16 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id y4so72553643wrm.2; Thu, 01 Aug 2019 01:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PXiN25QppzyjPh2mgBpX6eNUKSUCis/pzRiJyBG58uw=; b=Es+H3C0Q1DcwXnEVfXJuMKYjErsHiJ0q2WVd4LkRpp4Ujh0ATS5TgnJatditgDIKzo ZpVET5EOL32bhaJ72NpgwYCvlwhuryZicIxqo+QB549fkbvxLy7ssUjwjeKCSzmPMdxH Wy+3Wnv+u+w1RGNo2cfgjyY4RyM+4tG5LqRCDsn+xJSD5nECuRAs26eUfB0CIe4bxYci mtIW94117riNXlscXdh9/8GLhKBO4gcOuNxTuS/eqSolUhM45CZb1vGED2wPInLFekRi dyumTy0jTlclhHit+hfMXYctN2qh89bW4RAc1ftcysBW46khfKVJL7i2QthS1JA5OXgw E9Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PXiN25QppzyjPh2mgBpX6eNUKSUCis/pzRiJyBG58uw=; b=NDG35fVFzoAHO+u8L2ovmHQb19ObdoW5DfSZzz8gXO5KXYP0vjJNwVc6353CiIZtqL pxnCQgi7861z5Sc/+EG6nWAMaezKRKWEFcIMYANt6ggilwkaiFFNjCJ3ZXql8wMSakTL JByTveCFjDVyo2K4hNVW9SRF0v7OfjGlwFGeDzYlZE0JqZ3FbMqO4+SrdEi9lXNa59Qh +E6o1HVZte9hp+eyp1CI3BfvPXTMqzlPz5i2pwNtK4IOsP/hwxP5ZV94oBrIxvlnDhDi XT5Xzi5QxJjGrpSrmKl/nW1PB5j9+TpdrNz06FDEvG0RUkG7943gPLPymtQDMhzxUiQK KRBg== X-Gm-Message-State: APjAAAVRAanbsCXm3ekwMwWN2co3McaZ6bXBs8M8EvSEMJyDwSuB6LMG QoLc8hWSimyHvZKqvq8/3p1JRWNA1s071Q7MGL0= X-Google-Smtp-Source: APXvYqzp+xxs1Nq0kg6/2Hm9+VCfupGNqGCi6V9N50gzQ12EHmoswIQqwjCE0QMZ15A20y6xryebDHPQrXIX/jt5h5k= X-Received: by 2002:a5d:4a46:: with SMTP id v6mr29673575wrs.105.1564647314356; Thu, 01 Aug 2019 01:15:14 -0700 (PDT) MIME-Version: 1.0 References: <156156480691.19914.1926691912558233407@ietfa.amsl.com> In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Thu, 1 Aug 2019 17:14:38 +0900 Message-ID: To: Jan Lindblad Cc: "i2nsf@ietf.org" , YANG Doctors , draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org, IETF Discussion , skku_secu-brain_all@googlegroups.com, Brian Kim , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="0000000000005efd8e058f09d786" Archived-At: Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 08:15:21 -0000 --0000000000005efd8e058f09d786 Content-Type: text/plain; charset="UTF-8" Hi Jan, I will review your suggestion below and tell you our opinion later. Thanks a lot. Best Regards, Paul On Wed, Jul 31, 2019 at 5:21 PM Jan Lindblad wrote: > Paul, I2NSF team, > > Thanks for your volunteering to improve our Consumer-Facing Interface YANG > Module. > Could you propose a way to redesign ietf-i2nsf-cfi-policy.yang to befit > NACM? > > > Certainly. Find my proposed sketch for the module structure attached. > > I think it is important for the adoption of this module that it is > reasonably easy to implement it on top of existing NETCONF/RESTCONF/YANG > servers. They all implement the NACM management access control mechanism > today, so the ietf-i2nsf-cfi-policy module should build on that. It's > therefore important to leverage the existing NACM mechanisms and concepts > for groups, users, permissions. > > It would be technically possible to set up all the management access > control rules needed to implement the I2NSF ideas by only creating rules in > NACM. The NACM rules are massively more complex than the simple owner leaf > proposed in your YANG module, however. From a usability perspective I think > it makes good sense to keep the abstraction in ietf-i2nsf-cfi-policy and > let the module implementor make sure this high level authorization view is > translated into NACM specifics. > > In order to make this feasible, I changed the owner string leaf into a > leafref pointer to NACM groups, and removed the module's separate > identities for permissions. Let's adopt the NACM counterparts instead. The > structure of the rules was very flat, i.e. the domains, tenants, policies > and rules were mostly side by side, not reflecting their logical hierarchy > in the YANG. This would make the number of NACM rules to control access to > each individual item very high. By arranging them in a tree structure, I > believe the number of NACM rules can be kept to a minimum. NACM rules may > have a high impact on server performance, so it's important to not have > excessive amounts of them. > > I created a hierarchy with domains on top, each domain containing zero or > more tenants, each with zero or more policies that in turn consist of zero > or more rules. At each level it is possible to list owners in the form of > NACM groups. The module implementor would then have to translate these > owner references to actual NACM rules. > > Here is an example sketch configuration and the resulting NACM rules (in > CLI style syntax for readability): > > i2nsf-cfi domains domain example.com > owners [ example.com--eng-it ] > tenants tenant dev > policies policy team-black > owners [ example.com--dev ] > rules rule 2 > ! > rules rule allow-malware-sites > owners [ example.com--dev ] > > This is supposed to mean that members of the example.com--eng-it group > have full ownership of everything in the example.com domain. Within this > domain, there is a tenant called dev, with a policy called team-black. That > policy is owned by example.com--dev. This means this policy may be > updated by members in example.com--dev and example.com--eng-it. Within > the policy there are two rules ("2" and "allow-malware-sites"). The > "allow-malware-sites" rule has the example.com--dev group listed as > owner; this is superfluous. In this example, the rules are otherwise empty. > > In order for existing NC/RC/YANG servers to enforce the above, the > ietf-i2nsf-cfi-policy module implementation would need to translate the > intent above to NACM rules like the ones below. In this example, the > implementation created a rule to allow members of the dev and eng-it groups > within the example.com org to see the example.com domain and everything > within it. Next there is a rule to allow members of the example.com dev > group to update the policy named team-black within the dev tenant. Finally, > there is a rule to allow the eng-it group members to update anything within > the example.com domain. The default nacm policy per statement in the YANG > is to deny anyone else to see anything within the i2nsf domain. > > nacm rule-list example.com > group [ example.com--dev example.com--eng-it ] > rule read-all > path /i2nsf-cfi/domains/domain[name='example.com'] > access-operations read > action permit > ! > ! > nacm rule-list example.com--dev > group [ example.com--dev ] > rule 1 > path /i2nsf-cfi/domains/domain[name='example.com > ']/tenants/tenant[name='dev']/policies/policy[name='team-black'] > action permit > ! > ! > nacm rule-list example.com--eng-it > group [ example.com--eng-it ] > rule 1 > path /i2nsf-cfi/domains/domain[name='example.com'] > action permit > ! > ! > > NACM also contains a mapping from user names to groups. Is this in line > with your expectations? Do we need additional infrastructure to control > this mapping? > > nacm groups group example.com--dev > user-name [ jan vasilij ] > ! > nacm groups group example.com--eng-it > user-name [ chris victor ] > ! > nacm groups group example.com--finance > user-name [ clara sakura ] > ! > > What do you think about this approach to the management access control? > I'm not sure I got the relations between domains, tenants, policies and > rules as you want them. Are all these levels needed? Do you believe this is > this is a workable approach to your vision? > > Please let me know if you would like me to take any further steps with > this sketch. I should mention that I also have plenty of other comments on > your updated module, but I want to get the access control approach resolved > before looking at anything else. > > I am not aware of any particular party interested to implement our data > model. > > > Then it is all the more important that the solution can be implemented on > top of the existing servers out there without modifying them. > > Best Regards, > /jan > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --0000000000005efd8e058f09d786 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,
I will review your suggestion below and tell y= ou our opinion later.

Thanks a lot.

=
Best Regards,
Paul

On Wed, Jul 31, 2019 at 5:21 P= M Jan Lindblad <janl@tail-f.com&g= t; wrote:
Paul, I2NSF team,

Thanks for your volunteering to improve our Consumer-Facing Inte= rface YANG Module.
ietf-i2nsf-cfi-po= licy=C2=A0module should build on that. It's therefore important = to leverage the existing NACM mechanisms and concepts for groups, users, pe= rmissions.=C2=A0

It would be technically possible = to set up all the management access control rules needed to implement the I= 2NSF ideas by only creating rules in NACM. The NACM rules are massively mor= e complex than the simple owner leaf proposed in your YANG module, however.= From a usability perspective I think it makes good sense to keep the abstr= action in=C2=A0ietf-i2nsf-cfi= -policy=C2=A0and let the module implementor make sure this high leve= l authorization view is translated into NACM specifics.

In order to make this feasible, I changed the owner string leaf into = a leafref pointer to NACM groups, and removed the module's separate ide= ntities for permissions. Let's adopt the NACM counterparts instead. The= structure of the rules was very flat, i.e. the domains, tenants, policies = and rules were mostly side by side, not reflecting their logical hierarchy = in the YANG. This would make the number of NACM rules to control access to = each individual item very high. By arranging them in a tree structure, I be= lieve the number of NACM rules can be kept to a minimum. NACM rules may hav= e a high impact on server performance, so it's important to not have ex= cessive amounts of them.

I created a hierarchy wit= h domains on top, each domain containing zero or more tenants, each with ze= ro or more policies that in turn consist of zero or more rules. At each lev= el it is possible to list owners in the form of NACM groups. The module imp= lementor would then have to translate these owner references to actual NACM= rules.

Here is an example sketch configuration an= d the resulting NACM rules (in CLI style syntax for readability):

i2= nsf-cfi domains domain exa= mple.com
=C2=A0owners [ example.com--eng-it ]
=C2=A0tenants tenant dev
=C2=A0=C2=A0p= olicies policy team-black
=C2=A0 =C2=A0owners [ example.com--dev ]
=C2=A0 =C2=A0rules rule = 2
=C2=A0 =C2=A0!
=C2=A0 =C2=A0rules rule allow-malware-sites
=C2= =A0 =C2=A0=C2=A0owners [ e= xample.com--dev ]

This is supposed to m= ean that members of the ex= ample.com--eng-it group have full ownership of everything in the example.com domain. Within t= his domain, there is a tenant called dev, with a policy called team-black. = That policy is owned by ex= ample.com--dev. This means this policy may be updated by members in example.com--dev and example.com--eng-it. Withi= n the policy there are two rules ("2" and "allow-malware-sit= es"). The "allow-malware-sites" rule has the example.com--dev group listed as owne= r; this is superfluous. In this example, the rules are otherwise empty.

In order for existing NC/RC/YANG servers to enforce t= he above, the=C2=A0ietf-i2nsf= -cfi-policy=C2=A0module implementation would need to translate the i= ntent above to NACM rules like the ones below. In this example, the impleme= ntation created a rule to allow members of the dev and eng-it groups within= the example.com org t= o see the example.com = domain and everything within it. Next there is a rule to allow members of t= he example.com dev gro= up to update the policy named team-black within the dev tenant. Finally, th= ere is a rule to allow the eng-it group members to update anything within t= he example.com domain.= The default nacm policy per statement in the YANG is to deny anyone else t= o see anything within the i2nsf domain.

nacm rule-list example.com
=C2=A0group [ example.com--dev example.com--eng-it=C2=A0]
=C2= =A0rule read-all
=C2=A0=C2=A0path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0/i2nsf-cfi/domains/domain[name=3D'example.com']
=C2=A0=C2=A0access-ope= rations read
=C2=A0=C2=A0action=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0permit
=C2=A0!
!
nacm rule-list example.com--dev
=C2=A0group [ example.com--dev ]
=C2=A0rule 1
= =C2=A0=C2=A0path=C2=A0=C2=A0=C2=A0/i2nsf-cfi/domains/domain[name=3D'example.com']/tenants= /tenant[name=3D'dev']/policies/policy[name=3D'team-black']<= br>=C2=A0=C2=A0action permit
=C2=A0!
!
nacm rule-list example.com--eng-it
=C2=A0group [ example.com--eng-it ]
=C2=A0rule 1
=C2=A0=C2= =A0path=C2=A0=C2=A0=C2=A0/i2nsf-cfi/domains/domain[name=3D'example.com']
=C2=A0=C2=A0a= ction permit
=C2=A0!
!

NACM also cont= ains a mapping from user names to groups. Is this in line with your expecta= tions? Do we need additional infrastructure to control this mapping?
<= div>
nacm groups group example= .com--dev
=C2=A0user-name [ jan vasilij ]
!
nacm groups group = example.com--eng-it=C2=A0user-name [ chris victor ]
!
nacm groups group example.com--finance
=C2=A0user-na= me [ clara sakura ]
!

What do= you think about this approach to the management access control? I'm no= t sure I got the relations between domains, tenants, policies and rules as = you want them. Are all these levels needed? Do you believe this is this is = a workable approach to your vision?

Please let me = know if you would like me to take any further steps with this sketch. I sho= uld mention that I also have plenty of other comments on your updated modul= e, but I want to get the access control approach resolved before looking at= anything else.

I am not aware of any particular party intereste= d to implement our data model.

Then it is all the more important that the solution can be implemente= d on top of the existing servers out there without modifying them.

Best Regards,
/jan
<= div style=3D"overflow-wrap: break-word;">


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.<= br>Associate Professor
Department of Software
Sungkyunkwan University=
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@s= kku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-= jeong.php
--0000000000005efd8e058f09d786-- From nobody Mon Aug 5 03:20:28 2019 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B37120090; Mon, 5 Aug 2019 03:20:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: i2nsf@ietf.org Message-ID: <156500042662.24520.13787793616078439756@ietfa.amsl.com> Date: Mon, 05 Aug 2019 03:20:26 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 10:20:27 -0000 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 : Software-Defined Networking (SDN)-based IPsec Flow Protection Authors : Rafa Marin-Lopez Gabriel Lopez-Millan Fernando Pereniguez-Garcia Filename : draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt Pages : 86 Date : 2019-08-05 Abstract: This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based Network Security Function (NSF). The NSFs implement IPsec to protect data traffic between network resources. The document focuses on the NSF Facing Interface by providing models for configuration and state data required to allow the Security Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish Security Associations with a reduced intervention of the network administrator. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 7 06:15:16 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A101512004C; Wed, 7 Aug 2019 06:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PTEP7ibV-lq; Wed, 7 Aug 2019 06:15:10 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1AB1200F8; Wed, 7 Aug 2019 06:15:10 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id s3so10980wms.2; Wed, 07 Aug 2019 06:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KverjGxF+4z4eUpWlzasHCCsjFFwQRQTO8l2BgrqbsY=; b=HwfwxcGAxA5AxPVKeMlqkSBuXwT9k8MoI5s+2RddGCAgVchbLgDblP7T/oVwAq70Id TA7yw8J1vpv+jzr2DL6wSi3WrK7USksY+TNSOBd8xdXReyh2B3Qt1E71phCQKeX+oOlo qeyfMbdjGJNgkljLmBw2Y/bVBvwRSgyhHTo6rqJUOGbPCL83LxtAYr9KTVcjIxN8ix7H /X5WJq9blkkIwVKxcZ52qt5qjWYth/ZfrJuCgkw0QCfu1WosYZOAy/hWAK7eawTB93SQ LJoeDu8wwBMUrl6fu38MvjtiB34Mp5dn213oTo0WzRA54AfHAu+WM1W+GzXcBubUrVhz xs/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KverjGxF+4z4eUpWlzasHCCsjFFwQRQTO8l2BgrqbsY=; b=aoHLYNAyY64gjrj6D8sLdOOEXEKh1EuVv43Xs9iOPHcs+Esv5DTgcz/EFobfXcrxHo E6E5Sgyobv1Si5LmEHthyPkDzKrORvzlwueMoQWepkcTejojuJTy889T7NUXRGz8BvSG qKkwDD86jXknl5Vu+Ys8iPDJD5BQRu0aVDT2Tr1yRvnS7TzrZyyekzGxCidmhKM2z/+6 jjEWUaT5q6hvrMx+n/DPK7i7papKdNiMOZIPH1GJeZvTo0eilJaq7TobFR33vBeWQ/xC ekcYcTAL1Qj/MxPw1cV398r6gr5e+wk9Oh7r5rvdNEwauVnjaOBHl445m09flBKVfFnr haAw== X-Gm-Message-State: APjAAAUAki7DLSDQRJiSMMBGUbphLbboiIEtxdXIk0KCwUsqsGZuHVtP GyIdjaCm7dcbnfyAsI4UdX1KsBB2+gZ1zlDDoLA= X-Google-Smtp-Source: APXvYqw4TVmn1+wyP4GkM+MbZ6hZqVwciFJvb/NsOoBUjm2bWx+jq02d4IOPBaDKRiGu/dXI4b6NB4sWjkhZkx5HIQM= X-Received: by 2002:a7b:c30f:: with SMTP id k15mr5852458wmj.11.1565183708329; Wed, 07 Aug 2019 06:15:08 -0700 (PDT) MIME-Version: 1.0 References: <156156480691.19914.1926691912558233407@ietfa.amsl.com> In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Wed, 7 Aug 2019 22:14:32 +0900 Message-ID: To: Jan Lindblad Cc: "i2nsf@ietf.org" , YANG Doctors , draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org, IETF Discussion , skku_secu-brain_all@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000f17bed058f86ba98" Archived-At: Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 13:15:14 -0000 --000000000000f17bed058f86ba98 Content-Type: text/plain; charset="UTF-8" Hi Jan, Your suggestion looks good to my SKKU team and me. I agree with your suggestion that our Consumer-Facing Interface YANG data model leverages the existing NACM. Could you like me to take any further steps with your sketch? With your work, my team will be able to continue the revision of Consumer-Facing Interface YANG data model. Thanks. Best Regards, Paul On Wed, Jul 31, 2019 at 5:21 PM Jan Lindblad wrote: > Paul, I2NSF team, > > Thanks for your volunteering to improve our Consumer-Facing Interface YANG > Module. > Could you propose a way to redesign ietf-i2nsf-cfi-policy.yang to befit > NACM? > > > Certainly. Find my proposed sketch for the module structure attached. > > I think it is important for the adoption of this module that it is > reasonably easy to implement it on top of existing NETCONF/RESTCONF/YANG > servers. They all implement the NACM management access control mechanism > today, so the ietf-i2nsf-cfi-policy module should build on that. It's > therefore important to leverage the existing NACM mechanisms and concepts > for groups, users, permissions. > > It would be technically possible to set up all the management access > control rules needed to implement the I2NSF ideas by only creating rules in > NACM. The NACM rules are massively more complex than the simple owner leaf > proposed in your YANG module, however. From a usability perspective I think > it makes good sense to keep the abstraction in ietf-i2nsf-cfi-policy and > let the module implementor make sure this high level authorization view is > translated into NACM specifics. > > In order to make this feasible, I changed the owner string leaf into a > leafref pointer to NACM groups, and removed the module's separate > identities for permissions. Let's adopt the NACM counterparts instead. The > structure of the rules was very flat, i.e. the domains, tenants, policies > and rules were mostly side by side, not reflecting their logical hierarchy > in the YANG. This would make the number of NACM rules to control access to > each individual item very high. By arranging them in a tree structure, I > believe the number of NACM rules can be kept to a minimum. NACM rules may > have a high impact on server performance, so it's important to not have > excessive amounts of them. > > I created a hierarchy with domains on top, each domain containing zero or > more tenants, each with zero or more policies that in turn consist of zero > or more rules. At each level it is possible to list owners in the form of > NACM groups. The module implementor would then have to translate these > owner references to actual NACM rules. > > Here is an example sketch configuration and the resulting NACM rules (in > CLI style syntax for readability): > > i2nsf-cfi domains domain example.com > owners [ example.com--eng-it ] > tenants tenant dev > policies policy team-black > owners [ example.com--dev ] > rules rule 2 > ! > rules rule allow-malware-sites > owners [ example.com--dev ] > > This is supposed to mean that members of the example.com--eng-it group > have full ownership of everything in the example.com domain. Within this > domain, there is a tenant called dev, with a policy called team-black. That > policy is owned by example.com--dev. This means this policy may be > updated by members in example.com--dev and example.com--eng-it. Within > the policy there are two rules ("2" and "allow-malware-sites"). The > "allow-malware-sites" rule has the example.com--dev group listed as > owner; this is superfluous. In this example, the rules are otherwise empty. > > In order for existing NC/RC/YANG servers to enforce the above, the > ietf-i2nsf-cfi-policy module implementation would need to translate the > intent above to NACM rules like the ones below. In this example, the > implementation created a rule to allow members of the dev and eng-it groups > within the example.com org to see the example.com domain and everything > within it. Next there is a rule to allow members of the example.com dev > group to update the policy named team-black within the dev tenant. Finally, > there is a rule to allow the eng-it group members to update anything within > the example.com domain. The default nacm policy per statement in the YANG > is to deny anyone else to see anything within the i2nsf domain. > > nacm rule-list example.com > group [ example.com--dev example.com--eng-it ] > rule read-all > path /i2nsf-cfi/domains/domain[name='example.com'] > access-operations read > action permit > ! > ! > nacm rule-list example.com--dev > group [ example.com--dev ] > rule 1 > path /i2nsf-cfi/domains/domain[name='example.com > ']/tenants/tenant[name='dev']/policies/policy[name='team-black'] > action permit > ! > ! > nacm rule-list example.com--eng-it > group [ example.com--eng-it ] > rule 1 > path /i2nsf-cfi/domains/domain[name='example.com'] > action permit > ! > ! > > NACM also contains a mapping from user names to groups. Is this in line > with your expectations? Do we need additional infrastructure to control > this mapping? > > nacm groups group example.com--dev > user-name [ jan vasilij ] > ! > nacm groups group example.com--eng-it > user-name [ chris victor ] > ! > nacm groups group example.com--finance > user-name [ clara sakura ] > ! > > What do you think about this approach to the management access control? > I'm not sure I got the relations between domains, tenants, policies and > rules as you want them. Are all these levels needed? Do you believe this is > this is a workable approach to your vision? > > Please let me know if you would like me to take any further steps with > this sketch. I should mention that I also have plenty of other comments on > your updated module, but I want to get the access control approach resolved > before looking at anything else. > > I am not aware of any particular party interested to implement our data > model. > > > Then it is all the more important that the solution can be implemented on > top of the existing servers out there without modifying them. > > Best Regards, > /jan > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000f17bed058f86ba98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,
Your suggestion looks good to= my SKKU team and me.
I agree with your suggestion that our Consu= mer-Facing Interface YANG data model leverages the existing NACM.

Could you like me to take any further steps with your sketc= h?

With your work, my team will be able to continu= e the revision of Consumer-Facing Interface YANG data model.

=
Thanks.

Best Regards,
Paul=C2= =A0


On Wed, Jul 31, 2019 at 5:21 PM Jan Lindblad <janl@tail-f.com> = wrote:
Paul= , I2NSF team,

Thanks for your volunteering to improve our Consumer-Facing Inte= rface YANG Module.
ietf-i2nsf-cfi-po= licy=C2=A0module should build on that. It's therefore important = to leverage the existing NACM mechanisms and concepts for groups, users, pe= rmissions.=C2=A0

It would be technically possible = to set up all the management access control rules needed to implement the I= 2NSF ideas by only creating rules in NACM. The NACM rules are massively mor= e complex than the simple owner leaf proposed in your YANG module, however.= From a usability perspective I think it makes good sense to keep the abstr= action in=C2=A0ietf-i2nsf-cfi= -policy=C2=A0and let the module implementor make sure this high leve= l authorization view is translated into NACM specifics.

In order to make this feasible, I changed the owner string leaf into = a leafref pointer to NACM groups, and removed the module's separate ide= ntities for permissions. Let's adopt the NACM counterparts instead. The= structure of the rules was very flat, i.e. the domains, tenants, policies = and rules were mostly side by side, not reflecting their logical hierarchy = in the YANG. This would make the number of NACM rules to control access to = each individual item very high. By arranging them in a tree structure, I be= lieve the number of NACM rules can be kept to a minimum. NACM rules may hav= e a high impact on server performance, so it's important to not have ex= cessive amounts of them.

I created a hierarchy wit= h domains on top, each domain containing zero or more tenants, each with ze= ro or more policies that in turn consist of zero or more rules. At each lev= el it is possible to list owners in the form of NACM groups. The module imp= lementor would then have to translate these owner references to actual NACM= rules.

Here is an example sketch configuration an= d the resulting NACM rules (in CLI style syntax for readability):

i2= nsf-cfi domains domain exa= mple.com
=C2=A0owners [ example.com--eng-it ]
=C2=A0tenants tenant dev
=C2=A0=C2=A0p= olicies policy team-black
=C2=A0 =C2=A0owners [ example.com--dev ]
=C2=A0 =C2=A0rules rule = 2
=C2=A0 =C2=A0!
=C2=A0 =C2=A0rules rule allow-malware-sites
=C2= =A0 =C2=A0=C2=A0owners [ e= xample.com--dev ]

This is supposed to m= ean that members of the ex= ample.com--eng-it group have full ownership of everything in the example.com domain. Within t= his domain, there is a tenant called dev, with a policy called team-black. = That policy is owned by ex= ample.com--dev. This means this policy may be updated by members in example.com--dev and example.com--eng-it. Withi= n the policy there are two rules ("2" and "allow-malware-sit= es"). The "allow-malware-sites" rule has the example.com--dev group listed as owne= r; this is superfluous. In this example, the rules are otherwise empty.

In order for existing NC/RC/YANG servers to enforce t= he above, the=C2=A0ietf-i2nsf= -cfi-policy=C2=A0module implementation would need to translate the i= ntent above to NACM rules like the ones below. In this example, the impleme= ntation created a rule to allow members of the dev and eng-it groups within= the example.com org t= o see the example.com = domain and everything within it. Next there is a rule to allow members of t= he example.com dev gro= up to update the policy named team-black within the dev tenant. Finally, th= ere is a rule to allow the eng-it group members to update anything within t= he example.com domain.= The default nacm policy per statement in the YANG is to deny anyone else t= o see anything within the i2nsf domain.

nacm rule-list example.com
=C2=A0group [ example.com--dev example.com--eng-it=C2=A0]
=C2= =A0rule read-all
=C2=A0=C2=A0path=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0/i2nsf-cfi/domains/domain[name=3D'example.com']
=C2=A0=C2=A0access-ope= rations read
=C2=A0=C2=A0action=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0permit
=C2=A0!
!
nacm rule-list example.com--dev
=C2=A0group [ example.com--dev ]
=C2=A0rule 1
= =C2=A0=C2=A0path=C2=A0=C2=A0=C2=A0/i2nsf-cfi/domains/domain[name=3D'example.com']/tenants= /tenant[name=3D'dev']/policies/policy[name=3D'team-black']<= br>=C2=A0=C2=A0action permit
=C2=A0!
!
nacm rule-list example.com--eng-it
=C2=A0group [ example.com--eng-it ]
=C2=A0rule 1
=C2=A0=C2= =A0path=C2=A0=C2=A0=C2=A0/i2nsf-cfi/domains/domain[name=3D'example.com']
=C2=A0=C2=A0a= ction permit
=C2=A0!
!

NACM also cont= ains a mapping from user names to groups. Is this in line with your expecta= tions? Do we need additional infrastructure to control this mapping?
<= div>
nacm groups group example= .com--dev
=C2=A0user-name [ jan vasilij ]
!
nacm groups group = example.com--eng-it=C2=A0user-name [ chris victor ]
!
nacm groups group example.com--finance
=C2=A0user-na= me [ clara sakura ]
!

What do= you think about this approach to the management access control? I'm no= t sure I got the relations between domains, tenants, policies and rules as = you want them. Are all these levels needed? Do you believe this is this is = a workable approach to your vision?

Please let me = know if you would like me to take any further steps with this sketch. I sho= uld mention that I also have plenty of other comments on your updated modul= e, but I want to get the access control approach resolved before looking at= anything else.

I am not aware of any particular party intereste= d to implement our data model.

Then it is all the more important that the solution can be implemente= d on top of the existing servers out there without modifying them.

Best Regards,
/jan
<= div>

<= br>
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Profe= ssor
Department of Software
Sungkyunkwan University
Office: +82-31= -299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Per= sonal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<= /div>
--000000000000f17bed058f86ba98-- From nobody Wed Aug 7 07:44:56 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1FA12028E; Wed, 7 Aug 2019 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZc2851XUPTm; Wed, 7 Aug 2019 07:44:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7A93120287; Wed, 7 Aug 2019 07:44:46 -0700 (PDT) Received: from [10.147.40.106] (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A30B1AE0983; Wed, 7 Aug 2019 16:44:44 +0200 (CEST) From: Jan Lindblad Message-Id: <4F8FC316-8898-4A8F-B7BA-3ECEC752B36A@tail-f.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0258777C-23F5-48C5-9C19-FE1D25E9F641" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 16:44:43 +0200 In-Reply-To: Cc: "i2nsf@ietf.org" , YANG Doctors , draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org, IETF Discussion , skku_secu-brain_all@googlegroups.com To: "Mr. Jaehoon Paul Jeong" References: <156156480691.19914.1926691912558233407@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 14:44:54 -0000 --Apple-Mail=_0258777C-23F5-48C5-9C19-FE1D25E9F641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul, team, > Your suggestion looks good to my SKKU team and me. Ok, very good. Glad you liked it.=20 I should point out that even if I'm a YANG doctor, this is so far just = my own idea. Nobody in the NETMOD WG has given any kind of approval yet, = and I believe that will ultimately be necessary. I think the friction = should be much less when the module structure is like this, but it's = still far from an ordinary, mainstream module. > I agree with your suggestion that our Consumer-Facing Interface YANG = data model leverages the existing NACM. >=20 > Could you like me to take any further steps with your sketch? >=20 > With your work, my team will be able to continue the revision of = Consumer-Facing Interface YANG data model. Ok. I think you mean that I should wait for the i2nsf to produce a new = revision of the module, then review that module version. If this is not = what you mean, please tell me again what you would like me to do. Best Regards, /jan --Apple-Mail=_0258777C-23F5-48C5-9C19-FE1D25E9F641 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Paul,= team,

Your suggestion looks good to my SKKU team and = me.

Ok,= very good. Glad you liked it. 

I= should point out that even if I'm a YANG doctor, this is so far just my = own idea. Nobody in the NETMOD WG has given any kind of approval yet, = and I believe that will ultimately be necessary. I think the friction = should be much less when the module structure is like this, but it's = still far from an ordinary, mainstream module.

I agree with your suggestion that our Consumer-Facing = Interface YANG data model leverages the existing NACM.

Could you like me to = take any further steps with your sketch?

With your work, my team will be able to = continue the revision of Consumer-Facing Interface YANG data = model.

Ok. I think you mean that I should wait for the = i2nsf to produce a new revision of the module, then review that module = version. If this is not what you mean, please tell me again what you = would like me to do.

Best = Regards,
/jan

= --Apple-Mail=_0258777C-23F5-48C5-9C19-FE1D25E9F641-- From nobody Wed Aug 7 11:27:34 2019 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF3712028B; Wed, 7 Aug 2019 11:27:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-i2nsf-applicability@ietf.org, Linda Dunbar , i2nsf-chairs@ietf.org, Linda.dunbar@huawei.com, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156520244583.8361.3478438091440052143.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 11:27:25 -0700 Archived-At: Subject: [I2nsf] Alissa Cooper's Abstain on draft-ietf-i2nsf-applicability-16: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 18:27:26 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2nsf-applicability-16: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I largely agree with Mirja. The shepherd write-up says this document is called for in the WG charter, but I don't find that text in the charter. It's unclear why this document needs to be published as an RFC. From nobody Wed Aug 7 20:44:53 2019 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 410EC12000E; Wed, 7 Aug 2019 20:44:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-i2nsf-applicability@ietf.org, Linda Dunbar , i2nsf-chairs@ietf.org, Linda.dunbar@huawei.com, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156523589125.8250.10285230391287157267.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 20:44:51 -0700 Archived-At: Subject: [I2nsf] Barry Leiba's Abstain on draft-ietf-i2nsf-applicability-16: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 03:44:51 -0000 Barry Leiba has entered the following ballot position for draft-ietf-i2nsf-applicability-16: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don’t see that this is an applicability statement (see the meaning of that in RFC 2026). This is describing use cases, which is fine, but is not what it appears to be saying it’s doing, and doesn’t seem to have long-term value. From nobody Thu Aug 8 04:46:39 2019 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0161200D6; Thu, 8 Aug 2019 04:46:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-i2nsf-applicability@ietf.org, Linda Dunbar , i2nsf-chairs@ietf.org, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <156526479663.7695.12558363455507917341.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2019 04:46:36 -0700 Archived-At: Subject: [I2nsf] Alvaro Retana's Discuss on draft-ietf-i2nsf-applicability-16: (with DISCUSS) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 11:46:37 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-i2nsf-applicability-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document does provide a little more detailed view (than rfc8329) of the I2NSF Framework in that it does reference the models that make it up. However, these references are all Informative. I am Balloting DISCUSS because if the intent is to explain how the models apply to the scenarios, then their references should be Normative. I think this is an easy point to address. Regardless of the type of reference, I agree with others in the fact that this document presents use cases. While there is a deliverable in the WG Charter related to use cases, I think that was satisfied by rfc8192 (Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases). My understanding of the Charter is similar to Mirja's from the "Data Models and Applicability Statements" milestone. In order for this document to be an Applicability Statement, I believe that significant work is needed. This point is not part of my DISCUSS, so I will most likely end up ABSTAINing if the document remains in its current form. From nobody Thu Aug 8 22:07:44 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259B2120192; Thu, 8 Aug 2019 22:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzHVaiOE2eHt; Thu, 8 Aug 2019 22:07:22 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9AA120155; Thu, 8 Aug 2019 22:07:22 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id p13so22411904wru.10; Thu, 08 Aug 2019 22:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/iabA/vldkNpSG1Ih6tr0UAuHR1b0hSrHWEPJFS6v1U=; b=lQKcPDuFSPgY6lDwFgPz7eJlmxZ5JD2hcBus2hwUtKxUF34sALgmakFpreiAu/5LAW mIIGT1PILyWpa2gAZl8Gh8TqdEmZlsgKwx3B4DJiyI2ey1R3ltL7l143W6Az5H+Ulkpt izBOIYrRTcobaU6FaXbY7b58QaDvqQre8cJgvjsgH8bfQLvTdbvZCpzzrAGuEN1NSUI4 SoNWlE3hpJvorP8hkhby9trQLXYMFZyZnElNXq3wE3RZo+Zl9k+qFpmGcPFodFozttul LGRsGgf1ONqpAYURmVhcpLo6Gv5sJg330tyQcU4XN+BKC8M6xFOBMxRxTFmH9yP2SOJL HMhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/iabA/vldkNpSG1Ih6tr0UAuHR1b0hSrHWEPJFS6v1U=; b=s3gD1ZoeyJjl3Ue7WZfpH3/+wlUB9bP0MHyR/1tX1FwzlS/L6J8kcJQpK5QitYyqgz q2QghpRtBAXZ/NQyxuOp5Ymv4TxWvm5z1vl0T4s96HPrQgFAW+AzsWyGnarq/KzNSjDr R33e5hsHhOcDEEp6ippsBp5TBqR9+vlf/mE8JwUzzBn1+8/tuUzXIL9F5Wa5VLoUDKDQ fyevaQAGHWUINGwKns9c7QTgDuq2lvZEn4Vs6rwe4/uQhFtkWeXj8mSPNqUU/pODX37C QJVJ0dwELQqNAtd65oeLrlBpPi61ICcw0len0zG4I0XlRTXS/FP8dbYYDJi5UiKPTEhV og7g== X-Gm-Message-State: APjAAAXqNhSa1dgPZTtovvj/GT72oZmtO4NwYbQijefHLQnMNYUoA1TL GA+2f706XAqtdzf6pWoTmsghVIQ7WBhwrWcCZaY= X-Google-Smtp-Source: APXvYqwXlzroOrR0bmlIz0QL/pjj2uufJROhfK1RYauN/CropTvQ4VWdwC0AuJcbL5v6P2sBwEyfpU7AG5lu9i0w5Hs= X-Received: by 2002:a05:6000:1085:: with SMTP id y5mr13460957wrw.285.1565327240458; Thu, 08 Aug 2019 22:07:20 -0700 (PDT) MIME-Version: 1.0 References: <156526479663.7695.12558363455507917341.idtracker@ietfa.amsl.com> In-Reply-To: <156526479663.7695.12558363455507917341.idtracker@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 9 Aug 2019 14:06:44 +0900 Message-ID: To: Alvaro Retana Cc: The IESG , draft-ietf-i2nsf-applicability@ietf.org, Linda Dunbar , i2nsf-chairs@ietf.org, "i2nsf@ietf.org" , skku_secu-brain_all@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="0000000000001ffb80058fa8264d" Archived-At: Subject: Re: [I2nsf] Alvaro Retana's Discuss on draft-ietf-i2nsf-applicability-16: (with DISCUSS) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 05:07:36 -0000 --0000000000001ffb80058fa8264d Content-Type: text/plain; charset="UTF-8" Hi Alvaro, I am the editor of the I2NSF Applicability draft. Let me answer your comments inline below. On Thu, Aug 8, 2019 at 8:46 PM Alvaro Retana via Datatracker < noreply@ietf.org> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-i2nsf-applicability-16: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document does provide a little more detailed view (than rfc8329) of > the > I2NSF Framework in that it does reference the models that make it up. > However, > these references are all Informative. I am Balloting DISCUSS because if > the > intent is to explain how the models apply to the scenarios, then their > references should be Normative. I think this is an easy point to address. > => I will let the references be Normative in the next revision of our draft. > > Regardless of the type of reference, I agree with others in the fact that > this > document presents use cases. While there is a deliverable in the WG > Charter > related to use cases, I think that was satisfied by rfc8192 (Interface to > Network Security Functions (I2NSF): Problem Statement and Use Cases). My > understanding of the Charter is similar to Mirja's from the "Data Models > and > Applicability Statements" milestone. > > => This I2NSF Applicability draft enhances the use cases of I2NSF with the real implementation experience through 9 IETF Hackathons for the last three years. This draft describes how the I2NSF data models can be used for cloud-based security services, such as firewall, web filter, deep packet inspection, and DDoS attack mitigation, along with the SFC, SDN, and NFV at the aspect of the applicability of I2NSF to the real world. On the other hand, RFC 8192 just gives the audience high-level concepts for I2NSF use cases rather than the detailed use cases and applicability of I2NSF for real applications. I believe that this I2NSF applicability draft will be useful for the developers and operators to implement and operate the I2NSF system, so the publication of this draft to an RFC will be required. In order for this document to be an Applicability Statement, I believe that > significant work is needed. This point is not part of my DISCUSS, so I > will > most likely end up ABSTAINing if the document remains in its current form. > > => If you give me more detailed comments on how to improve this draft, I will work for the improvement of this draft with the co-authors of this draft. Thanks. Best Regards, Paul -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --0000000000001ffb80058fa8264d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,
I am the editor of the I2N= SF Applicability draft.
Let me answer your comments inline below.=

On Thu, Aug 8, 2019 at 8:46 PM Alvaro Retana via Datatrack= er <noreply@ietf.org> wrote:<= br>
Alvaro Retana ha= s entered the following ballot position for
draft-ietf-i2nsf-applicability-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-i2nsf-applicability/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document does provide a little more detailed view (than rfc8329) of th= e
I2NSF Framework in that it does reference the models that make it up.=C2=A0= However,
these references are all Informative.=C2=A0 I am Balloting DISCUSS because = if the
intent is to explain how the models apply to the scenarios, then their
references should be Normative.=C2=A0 I think this is an easy point to addr= ess.
=C2=A0=3D> I will let the references be Normat= ive in the next revision of our draft.=C2=A0

Regardless of the type of reference, I agree with others in the fact that t= his
document presents use cases.=C2=A0 While there is a deliverable in the WG C= harter
related to use cases, I think that was satisfied by rfc8192 (Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases).=C2=A0= My
understanding of the Charter is similar to Mirja's from the "Data = Models and
Applicability Statements" milestone.

=C2=A0=3D> This I2NSF Applicability draft enhances= the use cases of I2NSF with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the real = implementation experience through 9 IETF Hackathons for the last three year= s.
=C2=A0 =C2=A0 =C2=A0 =C2=A0This draft describes how the I2NSF = data models can be used for cloud-based security services,
=C2=A0= =C2=A0 =C2=A0 =C2=A0such as firewall, web filter, deep packet inspection, = and DDoS attack mitigation, along with
=C2=A0 =C2=A0 =C2=A0 =C2= =A0the SFC, SDN, and NFV at the aspect of the applicability of I2NSF to the= real world.
=C2=A0 =C2=A0 =C2=A0 =C2=A0On the other hand, RFC 81= 92 just gives the audience high-level concepts for I2NSF use cases rather t= han
=C2=A0 =C2=A0 =C2=A0 =C2=A0the detailed use cases and applica= bility of I2NSF for real applications.
=C2=A0 =C2=A0 =C2=A0 =C2= =A0I believe that this I2NSF applicability draft will be useful for the dev= elopers and operators
=C2=A0 =C2=A0 =C2=A0 =C2=A0to implement and= operate the I2NSF system, so the publication of this draft to an RFC will<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0be required.

In order for this document to be an Applicability Statement, I believe that=
significant work is needed.=C2=A0 This point is not part of my DISCUSS, so = I will
most likely end up ABSTAINing if the document remains in its current form.<= br>
=C2=A0=3D> If you give me more detailed comments o= n how to improve this draft,
=C2=A0 =C2=A0 =C2=A0 I will work for= the improvement of this draft with the co-authors of this draft.=C2=A0

=C2=A0 =C2=A0 =C2=A0 Thanks.

<= /div>
=C2=A0 =C2=A0 =C2=A0 Best Regards,
=C2=A0 =C2=A0 =C2=A0= Paul
--=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professo= r
Department of Software
Sungkyunkwan University
Office: +82-31-29= 9-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeong@skku.edu
Person= al Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
--0000000000001ffb80058fa8264d-- From nobody Thu Aug 8 22:13:05 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAF2120094; Thu, 8 Aug 2019 22:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke4002KQwbwx; Thu, 8 Aug 2019 22:13:00 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630FB120033; Thu, 8 Aug 2019 22:13:00 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id b3so4620132wro.4; Thu, 08 Aug 2019 22:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PZYOR9SuWgJROrVgkb2P1yk6e35ComltA2ea5lekXfg=; b=W1ahb1y99Of5s9cFZT4Ucazw8rDGgODaHMA8iEEmfKL6R1fsO0onowxOlsGAdG9SjL lhFiuRoSnAyqJhn/CNd9EZTEvr8U+mqkVnnn29owN+pp89OFmOKFGBtdK17oLV6PkYxn Ti7/d3F1w7hWGqeQMrH/VOuEUojCs33zgBRYnzwm9wFqQzgm24/3nrqSuBnqrr3cd1Aa ao+rT1YNAba4lyvqWSpSJzmH/5kNydA467RXQF01/UXqr+3Skyp/cMWO5JUo8D+mih0c p9BFj5ckBdVUHP14GJd+osuwQNPMCXnyUTRCGn54s7qd/T4+C3IwaNV6DjtYwDsO4d2d rnaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PZYOR9SuWgJROrVgkb2P1yk6e35ComltA2ea5lekXfg=; b=Gd4LRzkHAOTPwrpLI8FA0f9dbi89byBt47LV7Mi4ixdTBbftvbIqcJYQhOKzLwapeE HA7n5jColt1ci7vuhs1wh03ilBanPRsS52pehMkNUuauj+x5F9ox9t5OUx9QTUvXhAs6 YMmb6k10KcHILeOzERO9gVYGbbCpIPOCtyfHoJwo03hZI5KlO1wIUx0Tb22+6vZuHPTd BzvWkjN4+JFOFvTNiPQ2lywDgqs/AVsYVqCskpFB4dUEsyugkR9wyb3X0E6PqggqTch3 96brGRKF1iumoWh13enS5CJ9q8jmxWXic2aK1iZrhzaO1S3v6kaRj23NKjquDWzQvzxY QXiw== X-Gm-Message-State: APjAAAWJIyJcxZtVeoRB4XGyc6Ix7anSpgqEe2E/1pa8RX3c1290ysDJ 8k/7MZoy0XTAyvOlprl5AWSoVDBYyJNkPb7vSec= X-Google-Smtp-Source: APXvYqwAIctY87HNUO/C6RKM6rFRGrYb2X1V7aJ45I5KZHTVq5Sinun1q3rKXhN/QQtnxY4UHMLIzIoGTFzzt6c2ht4= X-Received: by 2002:adf:f281:: with SMTP id k1mr21511188wro.154.1565327578676; Thu, 08 Aug 2019 22:12:58 -0700 (PDT) MIME-Version: 1.0 References: <156156480691.19914.1926691912558233407@ietfa.amsl.com> <4F8FC316-8898-4A8F-B7BA-3ECEC752B36A@tail-f.com> In-Reply-To: <4F8FC316-8898-4A8F-B7BA-3ECEC752B36A@tail-f.com> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 9 Aug 2019 14:12:22 +0900 Message-ID: To: Jan Lindblad Cc: "i2nsf@ietf.org" , YANG Doctors , draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org, IETF Discussion , skku_secu-brain_all@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="00000000000048de2f058fa83a44" Archived-At: Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 05:13:03 -0000 --00000000000048de2f058fa83a44 Content-Type: text/plain; charset="UTF-8" Hi Jan, I will revise our Consumer-Facing Interface YANG Data Model according to your suggested sketch. Once the revision is done, I will let you know to review our revised YANG module. Thanks. Best Regards, Paul On Wed, Aug 7, 2019 at 11:44 PM Jan Lindblad wrote: > Paul, team, > > Your suggestion looks good to my SKKU team and me. > > > Ok, very good. Glad you liked it. > > I should point out that even if I'm a YANG doctor, this is so far just my > own idea. Nobody in the NETMOD WG has given any kind of approval yet, and I > believe that will ultimately be necessary. I think the friction should be > much less when the module structure is like this, but it's still far from > an ordinary, mainstream module. > > I agree with your suggestion that our Consumer-Facing Interface YANG data > model leverages the existing NACM. > > Could you like me to take any further steps with your sketch? > > With your work, my team will be able to continue the revision of > Consumer-Facing Interface YANG data model. > > > Ok. I think you mean that I should wait for the i2nsf to produce a new > revision of the module, then review that module version. If this is not > what you mean, please tell me again what you would like me to do. > > Best Regards, > /jan > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --00000000000048de2f058fa83a44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jan,
I will revise our Consumer-Facing Interface YA= NG Data Model according to your suggested sketch.
Once the revisi= on is done, I will let you know to review our revised YANG module.

Thanks.

Best Regards,
P= aul


On Wed, Aug 7, 2019 at 11:44 PM Jan Lindblad <janl@tail-f.com> wrote:
Paul, team,

Your = suggestion looks good to my SKKU team and me.

Ok, very good. Glad you liked it.=C2=A0

I should point out that even if I'm a YANG doctor, thi= s is so far just my own idea. Nobody in the NETMOD WG has given any kind of= approval yet, and I believe that will ultimately be necessary. I think the= friction should be much less when the module structure is like this, but i= t's still far from an ordinary, mainstream module.

I agree with your suggestion that our Consumer-Facing Interface YAN= G data model leverages the existing NACM.

Could yo= u like me to take any further steps with your sketch?

<= div>With your work, my team will be able to continue the revision of Consum= er-Facing Interface YANG data model.

Ok. I think you mean that I should wait for the i2nsf to = produce a new revision of the module, then review that module version. If t= his is not what you mean, please tell me again what you would like me to do= .

Best Regards,
/jan



-- <= br>
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon= (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Su= ngkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2= =A0pauljeong@skku.edu
Personal Homepage: http://iotlab.s= kku.edu/people-jaehoon-jeong.php
--00000000000048de2f058fa83a44-- From nobody Thu Aug 8 23:07:58 2019 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9791200EF; Thu, 8 Aug 2019 23:07:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: i2nsf@ietf.org Message-ID: <156533087122.7530.5282098615669264725@ietfa.amsl.com> Date: Thu, 08 Aug 2019 23:07:51 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-applicability-17.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 06:07:52 -0000 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 : Applicability of Interfaces to Network Security Functions to Network-Based Security Services Authors : Jaehoon Paul Jeong Sangwon Hyun Tae-Jin Ahn Susan Hares Diego R. Lopez Filename : draft-ietf-i2nsf-applicability-17.txt Pages : 24 Date : 2019-08-08 Abstract: This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-17 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-applicability-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-applicability-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 8 23:11:03 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBAC120091; Thu, 8 Aug 2019 23:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc8uKqrUpJTr; Thu, 8 Aug 2019 23:10:58 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785FC12004A; Thu, 8 Aug 2019 23:10:58 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id 31so97142170wrm.1; Thu, 08 Aug 2019 23:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OMvL8B/it+t7ldKifno4jMLiD5LIGfk2D3kAXfxnO4I=; b=o7hmn4I76TwC6URkNnJ2YZzR2LFxZCbHD4s810zjq2aM42SUyw+Q0m+unnyi/5TqdG 5SSz51eQMT5QC7+YOz+buBO3MD6XZAcmVXSWDKXJYuF7IxDXxWocysb8RK5VcF+/c4ta mx076KeIctDS1fwqdMReTaPvwrLi6CaSbmheOXgLLrj3iEYq7igCv0Y9T0ZindVhM+iD BPDjj8urrG+h46069SHCyHjkuYHYo275Zcj9HbdkVQk9vZDUyZO2sisxb+k7MASE8EUI vcYYBWSg3NmtxsNoKZrPZWOgFIVM0u3BUoE6CU2DlpcqRhUkhpywNdAVlQnfAG0qT14J P28Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OMvL8B/it+t7ldKifno4jMLiD5LIGfk2D3kAXfxnO4I=; b=qE1FwmeAe5uMFNQFS/yz92F5Thf/k+C+Mf2SmYdpyD0uvQgGkloPEh27wH8FdzxXDn AVkM0jo/M3TH0k78UAmZPKm+B29eUcdtEaRaabw9V8iPFtEuHHlbBlM50tvJjFo6cABv j+OMuVbAXs4v+NpkQc945Vtwpvb9VIILzXHvepWLV2dBWBNxqP8tuhiS5BruJsBllDEs kFlwM0GyKJwlDTu3/oDnKyXEKPrzgR06fbHGidPe+tl+cQ4vodL3+5LWajgGUyYXsSCM DWMBl5zyh+j7ILc7oOFITwASTC22r9Uwl/C6E70qRnqwSSpp98w3g5MIFvSkQ0Djwh8G lzBA== X-Gm-Message-State: APjAAAXUZHXeV6m4cFRfRSGlr3yy3fzWTP9iiuEYR3JGVUk50DdcsVMc sPGau1W3dQn95bPYc3Dr9RG+vulGBO1mevbzBuA= X-Google-Smtp-Source: APXvYqwN6ytfebzdi1Hd8tJ+tM+18zWiJMJBmTRBIcxmHwlO/xRYSq1hL5Tj8RfKMiCXmXegMrSgg60t1Fm7CsCV2gA= X-Received: by 2002:adf:f28d:: with SMTP id k13mr4479520wro.19.1565331056761; Thu, 08 Aug 2019 23:10:56 -0700 (PDT) MIME-Version: 1.0 References: <156450671162.14167.3810649609865720643.idtracker@ietfa.amsl.com> In-Reply-To: <156450671162.14167.3810649609865720643.idtracker@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Fri, 9 Aug 2019 15:10:20 +0900 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , "i2nsf@ietf.org" , draft-ietf-i2nsf-applicability@ietf.org, i2nsf-chairs@ietf.org, Linda Dunbar , skku_secu-brain_all@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000981f76058fa90935" Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-ietf?= =?utf-8?q?-i2nsf-applicability-16=3A_=28with_COMMENT=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 06:11:02 -0000 --000000000000981f76058fa90935 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, This applicability draft enhances the use cases in RFC 8192 (I2NSF Problem Statement and Use Cases) along with the I2NSF data models, considering the technologies for cloud-based security services such as SFC, SDN, and NFV. If you suggest a better title for this draft, it will be great. Also, I submitted a new version of this draft having an RFC and a draft of DOTS WG work as Normative references: https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-17 Thanks. Best Regards, Paul On Wed, Jul 31, 2019 at 2:12 AM Mirja K=C3=BChlewind via Datatracker < noreply@ietf.org> wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2nsf-applicability-16: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I find the title of this document rather misleading as the doc mainly > outlines > use cases. I would have expected that the boundaries of the applicability > of > i2nsf to certain scenarios are discussed which is not the case. My > understanding from the charter would further be that an applicability > statement > is connected to a specific data model (and I would also have expected tha= t > statement to be published in the same document). > > One minor additional comment: I'm surprised to only see a reference to > AVANT-GUARD but no mentioning of the IETF DOTS effort.... > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000981f76058fa90935 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,
This applicability draft enhances the use ca= ses in=C2=A0RFC 8192 (I2NSF Problem Statement and Use Cases)
=C2= =A0along with the I2NSF data models, considering the technologies for cloud= -based security services=C2=A0
such as SFC, SDN, and NFV.
If you suggest a better title for this draft, it will be great.

Also, I submitted a new version of this draft having an RF= C and a draft of DOTS WG work as Normative references:
=C2= =A0
Thanks.

Best Regards,
= Paul

On Wed, Jul 31, 2019 at 2:12 AM Mirja K=C3=BChlewind via Datatrac= ker <noreply@ietf.= org> wrote:
Mirja K=C3=BChlewind has entered the following ballot position for
draft-ietf-i2nsf-applicability-16: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-i2nsf-applicability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I find the title of this document rather misleading as the doc mainly outli= nes
use cases. I would have expected that the boundaries of the applicability o= f
i2nsf to certain scenarios are discussed which is not the case. My
understanding from the charter would further be that an applicability state= ment
is connected to a specific data model (and I would also have expected that<= br> statement to be published in the same document).

One minor additional comment: I'm surprised to only see a reference to<= br> AVANT-GUARD but no mentioning of the IETF DOTS effort....


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf


--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr= . Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Softw= are
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com= ,=C2=A0pauljeong@skku.edu
Personal Homepage: http://i= otlab.skku.edu/people-jaehoon-jeong.php
--000000000000981f76058fa90935-- From nobody Thu Aug 8 23:13:29 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7331200D7; Thu, 8 Aug 2019 23:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc5LUyRbmRUg; Thu, 8 Aug 2019 23:13:17 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4ED120096; Thu, 8 Aug 2019 23:13:16 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id b3so4723271wro.4; Thu, 08 Aug 2019 23:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xGS50oVDXvlGe7IqgzSIZXc68ICfEkHFPqX0/zn6tCg=; b=vBBZwTaJeZHjqj0moijajxaSQLeljnLd7YKUKAB8ptSXezHONW7Q47nQ4uyeLqOsZM D270o3s4DA1YA/k6b32tBzfqOWCd5IxDUjTGq64ata0RuYPl/GFxvqF+sywNXgGjiy6C s0BJ3wDAi/hX574iGVYf5MNG71lPHnAE2z1rZ137kumwPQiVRnymXrGjTKPE2HHfZsE3 tFkht1r64g7g+7q3YQV/IhFCfw/EIfKH05eUlIT6YBBEVtbsQOYK3s+D6p51RQy/qlZJ a0LKMKhNZRv629W7VC5zd86lY7fS0aQEIlnA38shD4dT7zjPyWFg4i7efzadWFDPDjhL aUCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xGS50oVDXvlGe7IqgzSIZXc68ICfEkHFPqX0/zn6tCg=; b=eoPtIBgUibRWUB04oLGa5W7dUJm1Hnuy++g3lHs08aidQqE2cB1Nn+lG867EynWKeh IgjIE5hGUE0/iS2l5sKtkYlQJKtgxJuBEbkKN4ron8nAjdZtxcmg+fyPB2z6/R5HO6Mf uOFIo3adWqhMLM1aF7sJ9pLuhoyx26nYGRoRZzriGaGOGG8APyppN5nVBMPjIIJWQj/S rrMbujCvptLu66lcnNIdOvk8ItiyfsS35Ncx51Yw0d9gkuGZMYcF2y8Of7+qRqHZW1O/ Dur0xcJpvRG1+/wgOe9ZBElVjebHh39o6HhvKspabXbc914vWkqV8K/L1SztEVL+EUEs M0yA== X-Gm-Message-State: APjAAAW3xReeP9Tz+g+q6NGDnUTq0RSufs1Lkk4hEnC0bMirQd+z+Px3 KXaehuvCzvvbsp6szcdh+D3593grFYCkMiP/b0U= X-Google-Smtp-Source: APXvYqxWdP5KsJOtqn2XrQp7IQWnAHe1jtJrvnXLLKpRrkOTZDP81jQ8BA0pn+f+hYms6XwXMQB25bZPyXCR81O2Vwc= X-Received: by 2002:a05:6000:1085:: with SMTP id y5mr13820006wrw.285.1565331195094; Thu, 08 Aug 2019 23:13:15 -0700 (PDT) MIME-Version: 1.0 References: <156526479663.7695.12558363455507917341.idtracker@ietfa.amsl.com> In-Reply-To: From: "Mr. Jaehoon Paul Jeong" Date: Fri, 9 Aug 2019 15:12:38 +0900 Message-ID: To: Alvaro Retana Cc: The IESG , draft-ietf-i2nsf-applicability@ietf.org, Linda Dunbar , i2nsf-chairs@ietf.org, "i2nsf@ietf.org" , skku_secu-brain_all@googlegroups.com, "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000d6ebe9058fa91197" Archived-At: Subject: Re: [I2nsf] Alvaro Retana's Discuss on draft-ietf-i2nsf-applicability-16: (with DISCUSS) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 06:13:21 -0000 --000000000000d6ebe9058fa91197 Content-Type: text/plain; charset="UTF-8" Alvaro, I submitted a new version having the data model drafts as Normative references: https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-17 Thanks. Best Regards, Paul On Fri, Aug 9, 2019 at 2:06 PM Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi Alvaro, > I am the editor of the I2NSF Applicability draft. > Let me answer your comments inline below. > > On Thu, Aug 8, 2019 at 8:46 PM Alvaro Retana via Datatracker < > noreply@ietf.org> wrote: > >> Alvaro Retana has entered the following ballot position for >> draft-ietf-i2nsf-applicability-16: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This document does provide a little more detailed view (than rfc8329) of >> the >> I2NSF Framework in that it does reference the models that make it up. >> However, >> these references are all Informative. I am Balloting DISCUSS because if >> the >> intent is to explain how the models apply to the scenarios, then their >> references should be Normative. I think this is an easy point to address. >> > => I will let the references be Normative in the next revision of our > draft. > >> >> Regardless of the type of reference, I agree with others in the fact that >> this >> document presents use cases. While there is a deliverable in the WG >> Charter >> related to use cases, I think that was satisfied by rfc8192 (Interface to >> Network Security Functions (I2NSF): Problem Statement and Use Cases). My >> understanding of the Charter is similar to Mirja's from the "Data Models >> and >> Applicability Statements" milestone. >> >> => This I2NSF Applicability draft enhances the use cases of I2NSF with > the real implementation experience through 9 IETF Hackathons for > the last three years. > This draft describes how the I2NSF data models can be used for > cloud-based security services, > such as firewall, web filter, deep packet inspection, and DDoS > attack mitigation, along with > the SFC, SDN, and NFV at the aspect of the applicability of I2NSF > to the real world. > On the other hand, RFC 8192 just gives the audience high-level > concepts for I2NSF use cases rather than > the detailed use cases and applicability of I2NSF for real > applications. > I believe that this I2NSF applicability draft will be useful for > the developers and operators > to implement and operate the I2NSF system, so the publication of > this draft to an RFC will > be required. > > In order for this document to be an Applicability Statement, I believe that >> significant work is needed. This point is not part of my DISCUSS, so I >> will >> most likely end up ABSTAINing if the document remains in its current form. >> >> => If you give me more detailed comments on how to improve this draft, > I will work for the improvement of this draft with the co-authors of > this draft. > > Thanks. > > Best Regards, > Paul > -- > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com, pauljeong@skku.edu Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php --000000000000d6ebe9058fa91197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alvaro,
I submitted a new version having the data mode= l drafts as Normative references:

= Thanks.

Best Regards,
Paul
On Fri, = Aug 9, 2019 at 2:06 PM Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi= Alvaro,
I am the editor of the I2NSF Applicability draft.
Le= t me answer your comments inline below.

On Thu, Aug 8, 2019= at 8:46 PM Alvaro Retana via Datatracker <noreply@ietf.org> wrote:
Alvaro Retana has entered the foll= owing ballot position for
draft-ietf-i2nsf-applicability-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-i2nsf-applicability/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document does provide a little more detailed view (than rfc8329) of th= e
I2NSF Framework in that it does reference the models that make it up.=C2=A0= However,
these references are all Informative.=C2=A0 I am Balloting DISCUSS because = if the
intent is to explain how the models apply to the scenarios, then their
references should be Normative.=C2=A0 I think this is an easy point to addr= ess.
=C2=A0=3D> I will let the references be Normat= ive in the next revision of our draft.=C2=A0

Regardless of the type of reference, I agree with others in the fact that t= his
document presents use cases.=C2=A0 While there is a deliverable in the WG C= harter
related to use cases, I think that was satisfied by rfc8192 (Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases).=C2=A0= My
understanding of the Charter is similar to Mirja's from the "Data = Models and
Applicability Statements" milestone.

=C2=A0=3D> This I2NSF Applicability draft enhances= the use cases of I2NSF with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the real = implementation experience through 9 IETF Hackathons for the last three year= s.
=C2=A0 =C2=A0 =C2=A0 =C2=A0This draft describes how the I2NSF = data models can be used for cloud-based security services,
=C2=A0= =C2=A0 =C2=A0 =C2=A0such as firewall, web filter, deep packet inspection, = and DDoS attack mitigation, along with
=C2=A0 =C2=A0 =C2=A0 =C2= =A0the SFC, SDN, and NFV at the aspect of the applicability of I2NSF to the= real world.
=C2=A0 =C2=A0 =C2=A0 =C2=A0On the other hand, RFC 81= 92 just gives the audience high-level concepts for I2NSF use cases rather t= han
=C2=A0 =C2=A0 =C2=A0 =C2=A0the detailed use cases and applica= bility of I2NSF for real applications.
=C2=A0 =C2=A0 =C2=A0 =C2= =A0I believe that this I2NSF applicability draft will be useful for the dev= elopers and operators
=C2=A0 =C2=A0 =C2=A0 =C2=A0to implement and= operate the I2NSF system, so the publication of this draft to an RFC will<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0be required.

In order for this document to be an Applicability Statement, I believe that=
significant work is needed.=C2=A0 This point is not part of my DISCUSS, so = I will
most likely end up ABSTAINing if the document remains in its current form.<= br>
=C2=A0=3D> If you give me more detailed comments o= n how to improve this draft,
=C2=A0 =C2=A0 =C2=A0 I will work for= the improvement of this draft with the co-authors of this draft.=C2=A0

=C2=A0 =C2=A0 =C2=A0 Thanks.

<= /div>
=C2=A0 =C2=A0 =C2=A0 Best Regards,
=C2=A0 =C2=A0 =C2=A0= Paul
--=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, = Ph.D.
Associate Professor
Department of Software
Sungkyunkwan Univ= ersity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0paulj= eong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-ja= ehoon-jeong.php


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.= D.
Associate Professor
Department of Software
Sungkyunkwan Univers= ity
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com,=C2=A0pauljeon= g@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaeho= on-jeong.php
--000000000000d6ebe9058fa91197-- From nobody Fri Aug 9 00:59:23 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE61200A4; Fri, 9 Aug 2019 00:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4w6WC7YKy73; Fri, 9 Aug 2019 00:59:11 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAC21200B3; Fri, 9 Aug 2019 00:59:11 -0700 (PDT) Received: from 200116b82cb1f800598a7c767f7fd8f5.dip.versatel-1u1.de ([2001:16b8:2cb1:f800:598a:7c76:7f7f:d8f5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvznk-0001a0-CU; Fri, 09 Aug 2019 09:59:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 9 Aug 2019 09:59:03 +0200 Cc: draft-ietf-i2nsf-applicability@ietf.org, "i2nsf@ietf.org" , skku_secu-brain_all@googlegroups.com, Linda Dunbar , The IESG , i2nsf-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <09A802B9-81FF-47E3-B62D-133450E4FB85@kuehlewind.net> References: <156450671162.14167.3810649609865720643.idtracker@ietfa.amsl.com> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565337551;e9684855; X-HE-SMSGID: 1hvznk-0001a0-CU Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-ietf?= =?utf-8?q?-i2nsf-applicability-16=3A_=28with_COMMENT=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 07:59:14 -0000 Hi Paul, I think replacing the word =E2=80=9CApplicability=E2=80=9D by =E2=80=9CUse= =E2=80=9D would do it, however, my point was rather that a real = applicability statement would have been more useful. Mirja > On 9. Aug 2019, at 08:10, Mr. Jaehoon Paul Jeong = wrote: >=20 > Hi Mirja, > This applicability draft enhances the use cases in RFC 8192 (I2NSF = Problem Statement and Use Cases) > along with the I2NSF data models, considering the technologies for = cloud-based security services=20 > such as SFC, SDN, and NFV. > If you suggest a better title for this draft, it will be great. >=20 > Also, I submitted a new version of this draft having an RFC and a = draft of DOTS WG work as Normative references: > https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-17=20 > =20 > Thanks. >=20 > Best Regards, > Paul >=20 > On Wed, Jul 31, 2019 at 2:12 AM Mirja K=C3=BChlewind via Datatracker = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2nsf-applicability-16: Abstain >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-applicability/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I find the title of this document rather misleading as the doc mainly = outlines > use cases. I would have expected that the boundaries of the = applicability of > i2nsf to certain scenarios are discussed which is not the case. My > understanding from the charter would further be that an applicability = statement > is connected to a specific data model (and I would also have expected = that > statement to be published in the same document). >=20 > One minor additional comment: I'm surprised to only see a reference to > AVANT-GUARD but no mentioning of the IETF DOTS effort.... >=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr.. Jaehoon (Paul) Jeong, Ph.D. > Associate Professor > Department of Software > Sungkyunkwan University > Office: +82-31-299-4957 > Email: jaehoon.paul@gmail.com, pauljeong@skku.edu > Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php From nobody Fri Aug 9 04:06:48 2019 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3304612014B; Fri, 9 Aug 2019 04:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wHcWI05M_lu; Fri, 9 Aug 2019 04:06:39 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A8B120128; Fri, 9 Aug 2019 04:06:39 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id e3so94584260edr.10; Fri, 09 Aug 2019 04:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=4QoM7+nkvX+nJk6wrBFIcDIN+fXwZbNVMwg5XRP8ADM=; b=Coeewx3kjXlifqxfBDdRh1qkZYir+oDSa8dgq4lq+Y+v/n3qdqWqJkNLbwhGsVzf49 bwPEXMvsGrK3+WEMCoTdM/ppL8GOtCX5tX4iCUXxGDrpPEH9TyW4ClbnkzNPBx+sbqK/ kR0YWpdYuN5Wj0lDi14sYniWjetjNLjf2fWveP5PG+QjXn9iTGYNeMF+o/2aznnZqD49 pa5xE9jsMiv+/4hkR0NN+IgnSJ/uLo4I9ae0Y55NSV2f1iX/SypNxDedWdlF2qtGnvpi m+QIl3YHaLgkS5yMuLJ1dvWntBeOHpGkJqHJM3PaYx4YcXYlttCf+r+40F2mrZ0r6YNf X3bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=4QoM7+nkvX+nJk6wrBFIcDIN+fXwZbNVMwg5XRP8ADM=; b=YMWxt6UKd6/39lrwfuCZoNqKV3JZyI0edVdd1IvpApz1VkQ6ZmZOyQSqCeqTXqMTFD k4CS4NeNzA09/A/1HxUm/U02iMfgnTPdWUOXetvudPBARCRWnQQm+MQoIIkCkBFLciMq z1KNOCHgqJPSQpSqY3Z/+QWyjUYR39AQqJU1PUhi21p6sx8Ua2zLGnR6sXYh2T/YiYRg trabNqDWYXIR4fZAFv8QnQQ4iChaHgQloD1jzgUxFbaNPEK/Mp+9rNcsUiq4NGyK7ayz vxqm4VqolNjAnI/yVDjEji/iTzgoH3YRXnVfYgSp/9deLWCxntFsrp1Nb1U/8E+hO6zV 5bTw== X-Gm-Message-State: APjAAAW/rWSzXQS9LQTUk1ypLmJ6XX+PhMNjJvHGUo6VCGBx4Kwnqnti q8gHnprkz5PlXNYuxdGFS8YTX50LVIT3h8vFCZ0= X-Google-Smtp-Source: APXvYqz5AflhKzW/qm7pBlIBuUir/RVA2/C4mBXUY0mUoSkAgFmLxO/AZAuJnAVLubApJuDYIUB3RLxwteoV4dmUZFE= X-Received: by 2002:a50:f982:: with SMTP id q2mr21223609edn.270.1565348798132; Fri, 09 Aug 2019 04:06:38 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Aug 2019 04:06:37 -0700 From: Alvaro Retana In-Reply-To: References: <156526479663.7695.12558363455507917341.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Fri, 9 Aug 2019 04:06:37 -0700 Message-ID: To: "Mr. Jaehoon Paul Jeong" Cc: draft-ietf-i2nsf-applicability@ietf.org, "i2nsf@ietf.org" , The IESG , skku_secu-brain_all@googlegroups.com, Linda Dunbar , i2nsf-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000000ff58b058fad2be5" Archived-At: Subject: Re: [I2nsf] Alvaro Retana's Discuss on draft-ietf-i2nsf-applicability-16: (with DISCUSS) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 11:06:42 -0000 --0000000000000ff58b058fad2be5 Content-Type: text/plain; charset="UTF-8" On August 9, 2019 at 2:13:15 AM, Mr. Jaehoon Paul Jeong ( jaehoon.paul@gmail.com) wrote: I submitted a new version having the data model drafts as Normative references: https://tools.ietf.org/html/draft-ietf-i2nsf-applicability-17 Thanks Paul! I have cleared my DISCUSS. Alvaro. --0000000000000ff58b058fad2be5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 9, 2019 at 2:13:15 AM, Mr. Jaehoon Pau= l Jeong (jaehoon.paul@gmail.com) wrote:

Thanks Paul!=C2=A0

I have cleared my DIS= CUSS.

Alvaro.


=
--0000000000000ff58b058fad2be5--