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

"Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com> Mon, 06 May 2019 15:24 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 6F002120091 for <netmod@ietfa.amsl.com>; Mon, 6 May 2019 08:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 2k5ivJbRAt35 for <netmod@ietfa.amsl.com>; Mon, 6 May 2019 08:24:32 -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 961AC12006D for <netmod@ietf.org>; Mon, 6 May 2019 08:24:32 -0700 (PDT)
Received: from fe0vm1649.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 44yRNs1S8Rz1XLG78; Mon, 6 May 2019 17:24:29 +0200 (CEST)
Received: from fe0vm02900.rbesz01.com (unknown [10.58.172.176]) by fe0vm1649.rbesz01.com (Postfix) with ESMTPS id 44yRNs0XHmz2H; Mon, 6 May 2019 17:24:29 +0200 (CEST)
X-AuditID: 0a3aad0c-d01ff700000039d6-24-5cd051acea33
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 fe0vm02900.rbesz01.com (SMG Outbound) with SMTP id 71.59.14806.CA150DC5; Mon, 6 May 2019 17:24:28 +0200 (CEST)
Received: from SI-MBX2054.de.bosch.com (unknown [10.3.230.148]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 44yRNr4ndHz523; Mon, 6 May 2019 17:24:28 +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; Mon, 6 May 2019 17:24:28 +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; Mon, 6 May 2019 17:24:28 +0200
From: "Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: NetMod WG <netmod@ietf.org>
Thread-Topic: Management Protocol Roles: Client/Server vs Manager/Agent
Thread-Index: AdUBk3PTS+EcD5D1QwG4flUjTOYwHwAJx4IAAJhVqNA=
Date: Mon, 6 May 2019 15:24:28 +0000
Message-ID: <341a6f3f0dd642f5b2231ac046c40e53@etas.com>
References: <941c9e23c3274dcdbca21c22348ca04f@etas.com> <20190503161450.p44lkz6cxzuwjc3d@anna.jacobs.jacobs-university.de>
In-Reply-To: <20190503161450.p44lkz6cxzuwjc3d@anna.jacobs.jacobs-university.de>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.35.83.170]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA22Tf0wbZRjHea/XcpTedhwrfcaomsv8RzMs6DZER/hnODUKm44Y08Rd5Wgr tCW9QlbQWGFmyHTFsUVogPFrxiCMHwpbDNtICyo4RrfAqBhZRWS4kZnFIRsqeMeVtX/4z5vv +zzP5/n15iVkdDuRSJitDs5uZQsZhRJXpndqd3Ts9+t11Z/q0iZ7HqC001c/kGdi+9raHmD7 ugdfzMHeVD6fxxWaSzj7UxmHlKbAqhsvCjCHg4vDmAv5kqpQDAHUM9DbtawQNU3VYdDki6tC SkF3IPjNO6GQLncQLPuP4dLlAoLFH3xyEVFQmTByvWId3yJod/+xdS2jHoWa+3exKkQQ8VQW HFl7VQp5Ae597AqFp4N7rCda1Di1HZqrb8tETVK7IbjQLpc6ehfGjnSvx8RQ2fDjahCJGlFa 6O4el0mlNDA9dxqTpqGgbUCyA6WG339dlUv6MZgavYlL8ckQOHUy1OaT8HnzRt04GKmbw6uR xhOR1hOBeCIQTwTShPB2lJDP6UosutRndbpku4HjS3UpyW/bLL1IeizVeTTcZvQiikCMityV 4tfTcraEd1q8aCeBMWryteZxPb3JYMtzmlje9Ja9uJDjmUQyyf+Sno5/aOaLDRYzz5ttVi8C QsZsIdn5K3qazGOdpZzdJmFetI3AGQ1pJLL1NGVkHVwBxxVx9g3vcwTBAFmfLfQQZ+eM3OF8 c6Fjw81oSRQVFUUnRHoiy2JEjBc9TaiE2kfFFCRfxFp4szGEb5VwesMaRkfRQWKw5ZcGGTGy LJ73js4K5/Ge+QYZjVttVi5RQ2bmCBkpkTUVWx/2lJhE+jDBoY5whPPeQlNI2Go8SYiwSvgl 4W6A3CYuMC5kDEOprQJD/RkP9bOvwN/nnNC4GsSh/NSCHIbn/5BDx+VpBZyobYyG84H2aPhw KRgNgYsBAgLzfymha60yFr4fcsfCzMV+FZw4M6qC2r4lEvq/vrYZLle7aGj0l9Nwv+MLGi6N fUtD5cokDTPjrWqY+3dRDRPDTQkw8cmlBGhp+Aqg0jMAMNQ/BDC9dHcrDLq6kuCjFvcjt4RF Y8KiGyvFR+YdrON/Fh2yhmdLdCGmzNIZayBnnD5Nc8zLN8renyueuuaeTc9v3VPHtBxyYKW5 aQetTWMnz03VZryzY/Mbm/quZ3dWeX66kJOhvs1f0X5X01Nf3nnT8PPxlb17e2FP1oD2LGSd Lei78V6FfvafLx13DqRe3b/g2709paZsRfnZgqFiV27uN49TBTmvT67tZHDexKY8IbPz7H+/ vfzTvQQAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/uTK1Pu_TGyfDIDe9GUkN1WsjjOg>
Subject: Re: [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: Mon, 06 May 2019 15:24:37 -0000

Hello Juergen,

thanks for feedback!

> It all boils down how you define the terms Manager and Agent. With NETCONF/RESTCONF and YANG, the initial focus was on the interaction between the server maintaining configuration datastores and the client manipulating configuration datastores (leaving out notifications for now, they actually came later).

The relevant role semantics originate at application level (and not at lower levels such as specific protocol layers), i.e., management applications (= the primary scope of NETCONF/RESTCONF).
That (native) roles are defined in ITU-T Recommendations X.701, M.3010, M.3700, and others, and in RFCs 3411, 3413, 3512, and others (in case of SNMP).
Crucial, underlying concept is the Management Application Context (often simply "context" in SNMP RFCs).
A manager gots normally exclusive access to a specific management application context. Multiple manager usually don't share the same application context (due to access conflicts, synchronization issues, etc).
That's why the 1:N ratio of management manager to management agent(s).

(I'm aware that these high-level management roles are further refined by e.g. considering the sub-roles of command generator, command responder, notification originator, notification receiver), see RFC 3413 or ITU-T X.703.)

Now, I had in mind that in client/server applications an application context is normally not distributed over multiple servers (but I might be wrong).

Anyway, looks like that I found in the meanwhile a hint to my question in RFC 6632, clause 1.3, stating the equation of:
(Management) Agent = NETCONF Management Server
(Management) Manager = NETCONF Management Client

Thanks again!
Albrecht

PS
An interesting exercise (for students?:-) might be the attempt to map NETCONF management roles on the distributed management architecture of ITU-T X.703, which differentiates the four roles of
- Managing client
- Managing server
- Managed client
- Managed server
with "Managing" = "Manager" and "Managed" = "Agent". :-)



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: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 
Sent: 03 May 2019 18:15
To: Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com>
Cc: Andy Bierman <andy@yumaworks.com>om>; NetMod WG <netmod@ietf.org>
Subject: Re: Management Protocol Roles: Client/Server vs Manager/Agent

On Fri, May 03, 2019 at 10:43:50AM +0000, Schwarz Albrecht (ETAS/ESY1) wrote:

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

The problem is that you leave the plural 's' out. ;-)

Client-to-Server  is 1:1 (= Manager-to-Agent) Client-to-Servers is 1:N (= Manager-to-Agents) Clients-to-Server is N:1 (= Managers-to-Agent)

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

It all boils down how you define the terms Manager and Agent. With NETCONF/RESTCONF and YANG, the initial focus was on the interaction between the server maintaining configuration datastores and the client manipulating configuration datastores (leaving out notifications for now, they actually came later).

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