Subject: [netmod] Issue Y36: associate a notification with a data node

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Jul 2014 18:09:07 +0000

Hello,
Ericsson would need this topic, but as someone has already raised: why just notifications, associating RPCs with data nodes would be even more important.
We see a number of reasons for this association:

1)      Access control: If RPCs and Notifications are associated to data nodes, it is enough to configure access control for the data node. Today, the operator needs to configure access control for the data nodes and after that separately for each RPC/notification again. Also understanding which action/rpc is carrying what data, thus how sensitive it is, which group should have access to it is not trivial. The operator has to read and understand all rpcs/notifications one by one. If the rpc/notification is generic (can relate to different parts of the data model), it cannot be access controlled properly at all. The amount of work needed by the operator for configuring access control is critical, if they have more work they have more room for mistakes, less likely to get it done properly.

2)      It is a natural way of thinking to associate notifications/rpcs with data items. If I want to reload a backup, I will look for the reload rpc in the backup branch of my model, not elsewhere.

3)      If we want RPCs with the same name (e.g. restart node, restart interface gracefully) but different parameters that cannot be done nicely today.

4)      For most of us YANG drives the CLI besides Netconf. In the CLI at the root of the model all rpcs will be available for the CLI user. So if the user calls help he will get a list of all rpcs. With more and more data models defined this results in dozens potentially hundreds of rpcs being listed. Unusable. If rpcs would be connected to the data nodes, then only a small number of relevant rpcs would be listed.

5)      All our(Ericsson's) internal model writers use and want rpcs connected to the data nodes.

AFAIK at least 3 separate implementations already use this feature.

So for these reasons we need rpcs/notifications connected to data nodes.
Regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2014 20:39:58 +0200

> 1)      Access control: If RPCs and Notifications are associated to data nodes, it is enough to configure access control for the data node. Today, the operator needs to configure access control for…

While I see your point, perhaps we need to study at how NACM today
works. Figure 2 in RFC 6536 seems to indicate that RPC access control
actually goes through write data node access control (but it seems to
bypass read data node access control, which surprises me). You have,
however, a point for RPCs that affect an underlying resource but not
any of the data nodes directly. But then I am not sure NACM would
without any changes actually apply the data node access control to an
execute permission of an RPC associated with a data node.

I guess I need Andy or Martin to help me understand whether
associating RPC and Notifications with data nodes actually gives you
what you are looking for or whether this also needs
changes/clarifications to RFC 6536.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Jul 2014 14:58:58 -0400 (EDT)

Juergen Schoenwaelder <[email-masked]> wrote:
> > 1) Access control: If RPCs and Notifications are associated to data
> > nodes, it is enough to configure access control for the data
> > node. Today, the operator needs to configure access control for the
> > data nodes and after that separately for each RPC/notification
> > again. Also understanding which action/rpc is carrying what data, thus
> > how sensitive it is, which group should have access to it is not
> > trivial. The operator has to read and understand all
> > rpcs/notifications one by one. If the rpc/notification is generic (can
> > relate to different parts of the data model), it cannot be access
> > controlled properly at all. The amount of work needed by the operator
> > for configuring access control is critical, if they have more work
> > they have more room for mistakes, less likely to get it done properly.
> > 
> 

In NACM, you can have a rule that looks like this:

  <rule>
    <name>xx</name>
    <path>/system/authentication/user[name=$USER]</path>
    <access-operations>exec</access-operations>
    <action>accept</accept>
  </rule>

(this would give a user access to any inline operations available for
a user, maybe 'generate-ssh-keys')

So while the NACM procedure defined in RFC 6536 doesn't spell out how
to handle inline operations (not surpringsly...) the data model
supports them.

I support Balazs in this; I think especially inline operations
(a.k.a. actions) have proven to be very useful.  We support them in
our software, and a majority of our customers use them.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 23 Jul 2014 19:07:28 +0000

Hello Juergen,
I am looking for multiple things, access control being one of them., but IMHO the others are also very important.

Regards Balazs

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, 23 July, 2014 14:40
To: Balázs Lengyel
Cc: [email-masked]
Subject: Re: [netmod] Issue Y36: associate a notification with a data node

> 1)      Access control: If RPCs and Notifications are associated to data nodes, it is enough to configure access control for the data node. Today, the operator needs to configure access control for…

While I see your point, perhaps we need to study at how NACM today works. Figure 2 in RFC 6536 seems to indicate that RPC access control actually goes through write data node access control (but it seems to bypass read data node access control, which surprises me). You have, however, a point for RPCs that affect an underlying resource but not any of the data nodes directly. But then I am not sure NACM would without any changes actually apply the data node access control to an execute permission of an RPC associated with a data node.

I guess I need Andy or Martin to help me understand whether associating RPC and Notifications with data nodes actually gives you what you are looking for or whether this also needs changes/clarifications to RFC 6536.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2014 21:16:19 +0200

> our software, and a majority of our customers use them.

Lets see what has happened. We discussed Y36 on 2014-06-04. Below is
the excerpt from the minutes. A call was made on the mailing list on
Fri, 27 Jun 2014 and nobody objected against the proposal to move this
to DEAD.

Why do we reconsider this now? What makes this a YANG 1.1 issue now?

/js

* Y36 associate a notification with a data node

  MB says that he did not have customers asking for this but Tail-f
  has something similar called actions (inlined rpcs). If we do this,
  it makes sense to add inline RPCs as well.

  AZ sees a use case.

  PO sees value in notification source properties attached to leafs.

  PO says that this is essentially about associating a notification
  with a resource object.

  MB says this is a nice to have feature because you can do
  without. Sounds more like a YANG 2.0 issue.

  AB agrees that this is an optimization, perhaps this can also be
  dealt with by certain design patterns.

  JS suggests that one could also think about guidelines on how to
  structure notifications to make resource identification easier.

  Proposal: Reject this issue. May be considered for YANG 2.0.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jul 2014 21:17:04 +0200

I do understand that.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jul 2014 12:33:07 -0700

Hi,

I think the NACM issues could be considered technical reasons to add this
new feature.
The important aspect to me is how intuitive the YANG constructs are to
users.

I like the idea of class-specific actions and events.
We don't have classes though, so I need to see more details
about how the nested actions and notification events are mapped
to NETCONF and RESTCONF.  How do these actions get invoked?
How do actions and notifications identify the object node and instance?
What happens if I have a top-level rpc called <reset> plus a lot of
node-specific actions called <reset>? How do they relate to each other
(in the model and in operation)?

Since we don't have classes, but we have groupings, then how can these
actions and events be used and refined from a grouping?

I think it would be worthwhile to see a solution proposal in writing before
ruling this out of YANG 1.1.

Andy

On Wed, Jul 23, 2014 at 11:58 AM, Martin Bjorklund <[email-masked]> wrote:

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

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 29 Jul 2014 15:40:57 +0200

Helo Juergen,
We should declare this issue alive because IETF is about rough consensus 
and running code:
- Rough consensus: Major players (Martin, Andy :-) ) and myself for 
Ericsson indicated strong interest and support (at least for connecting 
RPCs, a.k.a. actions, to data nodes). That is at least a begining for a 
consensus.
- Running code: Tail-f, Ericsson, and probably Huawei already has 
implementations of actions.

I have a reasonable proposal, which I will publish hopefully this week, 
but want to check with Martin first.
Also, actions are similar in many ways to RPCs so IMHO they are not a 
major new feature, no need to wait for a major YANG version: 2.0.
regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]