[netmod] Management Protocol Roles: Client/Server vs Manager/Agent

"Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com> Fri, 03 May 2019 10:43 UTC

Return-Path: <Albrecht.Schwarz@etas.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4509B12009A for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 03:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPd9T7jl-JiU for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 03:43:54 -0700 (PDT)
Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45944120026 for <netmod@ietf.org>; Fri, 3 May 2019 03:43:53 -0700 (PDT)
Received: from fe0vm1650.rbesz01.com (unknown [139.15.230.188]) by fe0vms0187.rbdmz01.com (Postfix) with ESMTPS id 44wTJR18bSz1XLDR3; Fri, 3 May 2019 12:43:51 +0200 (CEST)
Received: from si0vm4642.rbesz01.com (unknown [10.58.172.176]) by fe0vm1650.rbesz01.com (Postfix) with ESMTPS id 44wTJR0trQz1CW; Fri, 3 May 2019 12:43:51 +0200 (CEST)
X-AuditID: 0a3aad12-be3ff70000006e39-c8-5ccc1b66cf72
Received: from si0vm1950.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by si0vm4642.rbesz01.com (SMG Outbound) with SMTP id 86.74.28217.66B1CCC5; Fri, 3 May 2019 12:43:50 +0200 (CEST)
Received: from SI-MBX2054.de.bosch.com (unknown [10.3.230.148]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 44wTJQ69lcz52c; Fri, 3 May 2019 12:43:50 +0200 (CEST)
Received: from SI-MBX2054.de.bosch.com (10.3.230.148) by SI-MBX2054.de.bosch.com (10.3.230.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 3 May 2019 12:43:50 +0200
Received: from SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1]) by SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.006; Fri, 3 May 2019 12:43:50 +0200
From: "Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>
CC: NetMod WG <netmod@ietf.org>
Thread-Topic: Management Protocol Roles: Client/Server vs Manager/Agent
Thread-Index: AdUBk3PTS+EcD5D1QwG4flUjTOYwHw==
Date: Fri, 03 May 2019 10:43:50 +0000
Message-ID: <941c9e23c3274dcdbca21c22348ca04f@etas.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.129.237]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA21TfUwbdRjur9ePo/bYcVD6rh3B1BnjVynYKZHFbCZmIG4zTmeijXqMo+3W D9IrDIgmUDZlhI2FsQ2rG37AJHOODw1hphuskCik4oaudnXZ5mRDGCMShK0DwTuurP3Df355 3ud9nuf93fvL4Rh1FNfgVoebcTlom06mkCie/ybt6SJtwGToOJeTfX3AK8++1BlB2c0Xq6Qb sNyWlog4t6MvL3dP/UXJq9hbivWFjM1ayrgyXnhPYQmEfVjx4mNlcw3t8ko0k16LcBxII/SO v16LFDhFNonh6O0vpUJxCsHBuT0yoZhCMBcORYuzCMavtYtrUQIuIzfAYLBaxuMUkoE7V05g PMbIdDh0b3pZk0y+CN/3d0kFzSb4p64yqtfDQl3rsl5CrgVfzz7EY4J8DoJt1XIeIzINOjp+ jmaqITzavJwJJAktPoEHUgXjfy5KBfwwjPV0iwW9HkKHG2UCfhJOfH4bE/KTYPDjUclBpPLG xXrjLN44izfO8hmSnEQq1mootRufNWbpXQUMW2HI1O9w2ruQ8DxUD+oMFvkRiSOdkvhBETBR UrqULbf70TpcrFMRBhVHJRY4C8stNGt511ViY1idhlhz4WUTlfyAZksK7FaWtTodfgQ4pksh 3pkeMlFEIV1ewbicgs2PtLhEpybM+FYTRZppN7OLYYoZ10o3B8d1QNzScAOTXIyZKSuy2twr bV0agUQiEZUa34kfK8YT/OgZXMnNFvERBFtM21mrOWpfLdipFTZmHUJb8b4v/jiG4YN3+fNA 561jGCVxOB2MRk3k8Fkk77KUOB7cRrOGGFZyDVVcI5Y4gUKI22cyoV3NaZTcHxG7BxBafnVJ UTJmymrhPORIKnx6YzNEProghoVr8xJoOrtXCg1Nx+Wwd/a6HGbDwzicHmlNgHuTVxOgfanm IfhxoJ47Qn1KqAr3K6GhdUgJkflzBLS13yRgwPNJIlw+6U+E3sihVdD93cgqmPV0J0HN/UsU HPeNJUNosl8Fo/9OquDq1N8q+HV/bypcmbmZCkuN+9QwsXReDW3jw2qo8fpggtuxmNvxWAP/ vqybdv/PjqNs7OM0lciyQ4m17TzwPum4m7jwZr4+ZbF/S8Bi83i2zVRPBXb+/tdTj//y4SPh 4JmZgteYrKAhQzxnyv8p89v7Y7uGK37b+IqITd9Y17jbeEdk7godmd+d5z3c6nET2x49M51e q15b9UbeB287m8u+rl+foV1XeoOt237q/H7ndnjpNFw2bsr/SidhLXTmE5iLpf8DpE/7M6oE AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GsqEKBgSxDQWv7cmpcMEpHHKHKw>
Subject: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2019 10:43:58 -0000

Hello Andy, Juergen,

I got a side question for clarification (which was perhaps already discussed years ago on the list, but I'm just starting to follow NETCONF & NETMOD activities):

The management paradigm and management association is related to roles (Management) Manager (or Master) and (Management) Agents, in an hierarchical relationship of 1:N concerning the ratio of Manager to Agents.
That's the usual case, being aware of the exceptional cases with e.g. M:N (or additional, interim Management Broker, Gateway, etc entities).

I would have expected that 
- the Management Data Modeling language (YANG),
- the Management Datastore Architecture (RFC 8342),
- a Network Configuration Access Control Model (RFC 8341) and even
- Network Management Protocols for YANG data (such as NETCONF, RESTCONF)
use the role model of Manager and Agent.
However, I do see only the role relationship Client/Server (in that RFCs), hm?

Leading (for me) to a principle dilemma from (management) protocol engineering perspective due to
a) Manager-to-Agent = 1:N
b) Client-to-Server = N:1
c) and the mapping approach in NETCONF/NETMOD of Manager-to-Client and Agent-to-Server in my understanding.

I'm being aware that a distributed management solution needs to resolve the various role assignments in a layered management communication architecture at the various levels, e.g.,
for Management Application MA-over-RESTCONF-over-HTTP-over-TCP-over- ... as
1) Application level (MA): Manager to Agent(s)
2) Application layer management protocol = RESTCONF: Manager to Agent(s)
3) Session layer = HTTP: Client(s) to Server
4) Transport layer = TCP: Client(s) to Server

I fail to see, or do miss the background/justification why the notion of client/server is used in RFCs about YANG, NMDA, NETCONF? Instead of manager/agent.

Does anyone know the motivation, background?

Thanks,
Albrecht



Mit freundlichen Grüßen / Best regards

Dr. Albrecht Schwarz

Systems Engineering (ETAS/ESY1) 
Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | Albrecht.Schwarz@etas.com


-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Juergen Schoenwaelder
Sent: 03 May 2019 11:20
To: Andy Bierman <andy@yumaworks.com>
Cc: NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] validating a YANG action

On Fri, May 03, 2019 at 01:10:58AM -0700, Andy Bierman wrote:
> On Thu, May 2, 2019 at 10:57 PM Juergen Schoenwaelder < 
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Thu, May 02, 2019 at 04:15:28PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > The text about invoking actions in RFC 7950, sec. 7.15 is not 
> > > clear about whether the ancestor data nodes have to exist.
> > >
> > > sec 7.15.2, para 2:
> > >
> > >    The <action> element contains a hierarchy of nodes that 
> > > identifies the node in the datastore.
> > >
> > >
> > > The RFC does not say anything about if the data node is required 
> > > to exist or not.  There is no distinction between NP-container, 
> > > P-container, or list which are ancestors of the action node. It 
> > > does not specify which datastore, and that is not supplied in the <action> RPC.
> > > The text specifies what must be in the <rpc> request, not in any
> > datastore
> > > or state data.
> > >
> > > It seems like the intent is that no instance test is specified at 
> > > all and the corresponding ancestor nodes to the action node do not 
> > > have to exist for the action to be invoked. (The action may succeed or fail).
> > > The issue is whether there is an existence-test before invoking 
> > > the
> > action.
> >
> > We discussed actions during the work on NMDA. RFC 8342 has this text 
> > in section 6, in particular 6.1 says:
> >
> >    Actions are always invoked in the context of the operational state
> >    datastore.  The node for which the action is invoked MUST exist in
> >    the operational state datastore.
> >
> >
> This only applies to a server implementing NMDA.
> There is no requirement for a server implementing RFC 7950 to make 
> this test.
>

Yes, the behavior is unspecified in RFC 7950. However, note that RFC
8342 formally updates RFC 7950 and the Introduction section says:

   This document updates RFC 7950 by refining the definition of the
   accessible tree for some XML Path Language (XPath) context (see
   Section 6.1) and the invocation context of operations (see
   Section 6.2).

This update may not affect your implementation but since you asked whether there is an existence-test before invoking the action, I thought a pointer to RFC 8342 is perhaps relevant.

/js

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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod