Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05

"Mr. Jaehoon Paul Jeong" <> Wed, 06 November 2019 02:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD523120274; Tue, 5 Nov 2019 18:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y5nKsB72IKiq; Tue, 5 Nov 2019 18:05:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3464120236; Tue, 5 Nov 2019 18:05:52 -0800 (PST)
Received: by with SMTP id n21so10560304ljg.12; Tue, 05 Nov 2019 18:05:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IiIL28iyedE/T/k4KjIdf7X8XR6qSJsqFocKKE6bbs8=; b=G8sXad9Btbg1UYPSXT/I3qjQztRc+hYJo5v3rqFOdaV0/AHRmbKlbjPqjrRdyN0EOY ScTnuqDBgWxWGHybeGtuz+4hav0S0IfK7K50pDL1lkKPT46RslokWRhxrkHq2/Ecph+a Nf8Zv0PFH43d095astQshDbHVoOmdgkwU4Yi48eyNON/wxMknK6i67DcAVFODzo4B+Sd b37WOFGzoygeiBSbll5jnFyDCtNROU+NAsPPz5ALOmWcThlYu3JhldhwEyBFx0euBx00 nG4dzD4wrqSYfzXd5ZbtsKFKKyOTPSywlRFcgzTLogRXyq4+R+GLYNxt70cyY5WJaB96 iqXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IiIL28iyedE/T/k4KjIdf7X8XR6qSJsqFocKKE6bbs8=; b=O+9Nb2sv8JUn+uGIV9zDiCMC+0yYBAep0eUhr/FyFNKVAQbANcbnqKDIB5E/RKrwjl yDorR8FpYQOdFbIsObR0pYVDfXO9ACn/k4TblGNjJzJ5SzWkkCBZEZPpwxk0mUq/yma8 4CQRf70LKH1RSk3rTBekrFnCKtUOi2dX6sHWavK7Io//fEbAc4gxuWng3tj1Y9rmO7Qs nn3bRXBjn1iBEuiqbJVCn4NcSUo7acGxv2kouL4WAul10yro0sQNZPBiXaN/alld1G/1 LRto1OYcDW7VHBzsJiUQWLIO5hcjkjZfpOSUJFgS6HCKJtQUkh8NzJeGXud58e2L+I6A n/qQ==
X-Gm-Message-State: APjAAAWGsNvrvdLbX5ED+cdsO0QP5/s8lRJ7tfBCPGjBHNpw9P7Uu9Mb bFlRthSjMiTaLvCnE3sstADG/oD1wDXhTzCWzUM=
X-Google-Smtp-Source: APXvYqyHhAIv7UljgnJgySDG7ItCwVtbNM3nLnxIr/2eiU2ftoN0+U06vvO/9Xehd/xmKo8osP3IA0GzCQpH3bX9w5g=
X-Received: by 2002:a2e:91d5:: with SMTP id u21mr15270900ljg.32.1573005950892; Tue, 05 Nov 2019 18:05:50 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: "Mr. Jaehoon Paul Jeong" <>
Date: Wed, 6 Nov 2019 11:05:15 +0900
Message-ID: <>
To: Jan Lindblad <>
Cc: "" <>, YANG Doctors <>,,, "Mr. Jaehoon Paul Jeong" <>
Content-Type: multipart/alternative; boundary="000000000000eec3d80596a3fc08"
Archived-At: <>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05
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, 06 Nov 2019 02:05:56 -0000

Hi Jan,
I believe that I have addressed your comments on I2NSF Consumer-Facing
Interface Data Model:

If you are satisfied with the revision, could you update the Review result
in the following page?


Best Regards,

On Tue, Nov 5, 2019 at 6:03 PM Mr. Jaehoon Paul Jeong <> wrote:

> Hi Jan,
> I have revised the Consumer-Facing Interface Data Model draft according to
> your guideline as follows:
> I attach a revision letter to explain how I revised this draft according
> to your comments.
> If you have further comments, please let me know.
> 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
>>  owners [ ]
>>  tenants tenant dev
>>   policies policy team-black
>>    owners [ ]
>>    rules rule 2
>>    !
>>    rules rule allow-malware-sites
>>     owners [ ]
>> This is supposed to mean that members of the group
>> have full ownership of everything in the domain. Within this
>> domain, there is a tenant called dev, with a policy called team-black. That
>> policy is owned by This means this policy may be
>> updated by members in and Within
>> the policy there are two rules ("2" and "allow-malware-sites"). The
>> "allow-malware-sites" rule has the 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 org to see the domain and everything
>> within it. Next there is a rule to allow members of the 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 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
>>  group [ ]
>>  rule read-all
>>   path              /i2nsf-cfi/domains/domain[name='']
>>   access-operations read
>>   action            permit
>>  !
>> !
>> nacm rule-list
>>  group [ ]
>>  rule 1
>>   path   /i2nsf-cfi/domains/domain[name='
>> ']/tenants/tenant[name='dev']/policies/policy[name='team-black']
>>   action permit
>>  !
>> !
>> nacm rule-list
>>  group [ ]
>>  rule 1
>>   path   /i2nsf-cfi/domains/domain[name='']
>>   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
>>  user-name [ jan vasilij ]
>> !
>> nacm groups group
>>  user-name [ chris victor ]
>> !
>> nacm groups group
>>  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:,
> Personal Homepage:
> <>

Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Personal Homepage: