Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Feb 2015 22:29:52 +0100

On Thu, Nov 13, 2014 at 12:02:07PM -0800, Andy Bierman wrote:
> On Thu, Nov 13, 2014 at 11:40 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > Andy,
> >
> > given Martin's clarification, are you find the proposed resolution of
> > Y58?
> 
> I do not see any text proposing how to fix NACM.
> Adding actions and notifications to the datastore is an architectural hack.
> The ARCH (RFC 6244) needs to support it. NACM (RFC 6536) needs
> to support it.
> 
> I strongly object to adding this feature to YANG without proper support in
> all protocols that use YANG.  The feature is nice-to-have, not required
> to fix anything broken.  But if the fix is half-baked and incomplete across
> all impacted standards, then I cannot support it anymore.
>

The NETCONF chairs meanwhile confirmed that a corresponding NACM
update can be done in NETCONF. And update of the informational
document RFC 6244 may be nice to do as well but this is not considered
strictly necessary since it is not defining a protocol. Thus I believe
we have resolved this objection.

I will assume this VRFY has passed by Friday 2015-02-20 unless new
objections are raised. I notice that several implementations seem to
exist and that data model writers and data model implementers found
this feature useful.

/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: Andy Bierman <[email-masked]>
Date: Fri, 13 Feb 2015 13:47:53 -0800

> we have resolved this objection.

I don't have any objections to adding this new feature.
Not all the solution details are worked out, but that's OK.

> exist and that data model writers and data model implementers found

I think Phil strongly objected to this because is is a duplicate of "rpc",
and it gives the appearance of OO-design, but YANG 1.1 should not
introduce any changes like that.

Have these objections been addressed?

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Feb 2015 10:25:14 +0100

> Have these objections been addressed?

There was a strong objection from you because NACM requires an update
to handle this and I have tried to resolve that.

Phil has expressed that he things actions are not needed but he did
not phrase it as a strong objection - at least I did not read it as
such. There are implementations of actions that are being actively
used and deployed. I do not think an argument that associating actions
(or RPCs) with resources may eventually lead to OO and OO is evil is a
strong argument. It seems that implementations actually benefit from
this and deployments benefit from simpler access control mechanisms
since it is possible to express that all actions associated with a
certain resource have certain permissions.

We have to find concensus and concensus can be rough. Concensus does
not require that everybody will be happy - the concensus process is
about making sure the technical arguments have been heard, understood
and taken into account while trying to find a resolution.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Feb 2015 09:48:33 -0800

> to handle this and I have tried to resolve that.

My objection was to any attempt at an incomplete solution.
Once NACM is open for edits, we need to make sure it
doesn't need any other edits for I2RS or anything else.

IMO the I2RS "owner-based" access control is not RIB-specific at all.
I hope we don't develop a different toolset for every subtree in the server.
Nice features like "delete all for owner X" are not RIB-specific either.

That doesn't mean I think NACM or I2RS should boil the ocean.
Just be mindful of general purpose features that are only protocol-specific
because the WG charter says so.

> and taken into account while trying to find a resolution.

I hope the YANG spec is clear about when to use rpc-stmt vs. action-stmt.
I agree with Phil that the functionality between the 2 are quite similar.
The name "action" implies that I cannot use it for retrieval or altering
the configuration, but this is not the case.  There is significant potential for
misuse like "edit" (with a different behavior and set of inputs for each
occurrence).

Andy