Subject: [Netconf] Should NC/RC-client models be groupings (not containers)?

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Jun 2017 17:28:02 +0000

This is my last issue from Chicago.
Here's the slide I presented then:

  Having a container for NC/RC-servers makes sense
    - since the server's backend must have the code implementing
      the modules it supports.

  But clients are different
    - A client must have business logic of some sort to do something.  
      Specifically, an NC/RC client needs to be linked into an application
      that orchestrates its function.

  That being the case, how can a client ever be configured on its own?  
    - Shouldn't the application itself be the thing that is configured? 

  Should these client models be groupings instead of containers?

To be clear, assuming no objections, I plan to convert ietf-netconf-client
and ietf-restconf-client from defining a container to defining a grouping.

Thoughts?

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 10 Jun 2017 08:49:07 +0200

> and ietf-restconf-client from defining a container to defining a grouping.

In the LMAP working group, we have RC clients that are co-located with
an RC server and these combinations are distributed in the network to
do measurements.  (The RC clients are used to post measurement results
to an RC server.) So for this use case, it would be nice to have a
concrete data model that can be implemented.

So why not do both, define proper groupings but also offer an
instantiation of the groupings that can be used directly?

/js

PS: I do not really see the difference between an application or a
    router - both can have modular configuration data models. I think
    the real difference is that we usually do not expect applications
    to be configurable via NC/RC.

-- 
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/>