Subject: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification

From: STUART VENTERS <[email-masked]>
Date: Fri, 4 Mar 2016 16:25:37 +0000

With respect to the Mount draft.

I like the goal of being able to take an assortment of device models (D1..Dn) and merge them in a scalable manner into a single aggregate model (A).

My use case is a management interface aggregator.  A sort of middle box with multiple netconf interfaces on the managed device side and one netconf interface on the manager side.  In my case, one that performs persistence and pre-provisioning in addition to aggregation.

The draft proposes to do this by adding a new syntax 'mount' along with supporting semantics.
  While adding yet another syntax to Yang is a possibility, I'd like to propose something else.
  Specifically, I'd like to adjust the semantics for 'uses', 'rpc' and 'notification' and keep the appearance of the current syntax.

1)      Allow the 'uses' verb to use a module in addition to groupings.

2)      Allow the 'rpc' and 'notification' nouns to be used in other places in the schema tree besides at the top module level.

Given these features, I see them being used three ways.
   First to mount  D on A by modifying D, write augment A.
   Second to mount D on A by modifying A, write uses D.
   Third to mount D on A with a third separate module, write augment A uses D.

At a protocol level, I guess data would just be deeper in the tree.
Rpc and notification would now need a prefix to their name to show where in the tree they are from.

I wonder if others will see this as a more consistent and general purpose adjustment to Yang/Netconf.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Mar 2016 17:52:19 +0100

> 2)      Allow the 'rpc' and 'notification' nouns to be used in other places in the schema tree besides at the top module level.

This is already part of YANG 1.1.

/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: t.petch <[email-masked]>
Date: Wed, 16 Mar 2016 12:26:17 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, March 04, 2016 4:52 PM

> > 2)      Allow the 'rpc' and 'notification' nouns to be used in other
places in the schema tree besides at the top module level.
> This is already part of YANG 1.1.

Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing in
many places so indeed it is allowed in other places but only see
'rpc-stmt' appear in 'body-stmts' .  Which, if I understand aright,
means that 'rpc-stmt' can still only appear at the top level.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2016 15:08:28 +0100

> means that 'rpc-stmt' can still only appear at the top level.

Yep. But there is a new action-stmt and in section 1.1 it says:

   o  Added a new statement "action" that is used to define operations
      tied to data nodes.

/js

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 16 Mar 2016 14:58:08 +0000

Interesting, this highlights a concern I have with Yang.
It's highlevel goals and progress are great, but at a detail level,
   instead of using one general purpose language construct per feature, it seems to be evolving to use many.
For a new language evolving in an old problem area, this doesn't seem right.

RFC6020bis-11 section 7.15 gives some clue as to the reasoning behind this.
"The difference between an action and an rpc is that an action is tied
   to a node in the datastore, whereas an rpc is not."

To me, this feels like a protocol or implementation issue is causing an unnecessary language addition.

I wonder if an alternative strategy could be to say that you can use an rpc in a node, but when you do the name of the rpc on the wire becomes some combination of the node name and the rpc name?

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2016 9:08 AM
To: t. petch
Cc: STUART VENTERS; [email-masked]; Martin Bjorklund
Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2016 16:07:57 +0100

Speaking with my WG chair hat on, I think it is a bit late to discuss
the design of actions. The WG has been working on YANG 1.1 for almost
two years and unless something is really broken in the specification I
am not going to take the specification back from where it is now,
namely the processing pipeline of the IESG. It is time to deliver and
then use all the good stuff that is in YANG 1.1.

/js

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 16 Mar 2016 16:28:36 +0000

Juergen,

Agreed, given where you are in the process, the Yang1.1/action ship has sailed. 

 At this point, if the feedback is valid (consensus for which hasn't been shown), 
   it only provides an Occam's Razor reminder for  thinking about how to add future features.

If the mount ship has not sailed, then mount might be one of those future features.

Cheers,
Stuart

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2016 10:08 AM
To: STUART VENTERS
Cc: [email-masked]; Martin Bjorklund
Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount / possible simplification

Speaking with my WG chair hat on, I think it is a bit late to discuss the design of actions. The WG has been working on YANG 1.1 for almost two years and unless something is really broken in the specification I am not going to take the specification back from where it is now, namely the processing pipeline of the IESG. It is time to deliver and then use all the good stuff that is in YANG 1.1.

/js

On Wed, Mar 16, 2016 at 02:58:08PM +0000, STUART VENTERS wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing 
> > in many places so indeed it is allowed in other places but only see

---

From: t.petch <[email-masked]>
Date: Fri, 18 Mar 2016 12:27:51 +0000

----- Original Message -----
From: "STUART VENTERS" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 16, 2016 2:58 PM

>    instead of using one general purpose language construct per
feature, it seems to be evolving to use many.
> I wonder if an alternative strategy could be to say that you can use
an rpc in a node, but when you do the name of the rpc on the wire
becomes some combination of the node name and the rpc name?

Stuart

Picking up on your earlier e-mail, I agree with your thoughts but accept
Juergen's point that we should have got involved a year or two ago.

What I think would be valuable now is more guidance on when to choose
which option of the several available, like RFC6087 only more so.  I
think of this whenever I see a discussion on this list about e.g.
identities, enumerations, derived types, ...references and such like.
There are good reasons why one option is better than another but I
struggle to understand them and rarely remember when I am looking at one
of the dozens of YANG models that come out each month.

Tom Petch
> > Looking at rfc6020bis-11 s.14, I see 'notification-stmt' appearing
in
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod