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

"Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com> Wed, 08 May 2019 09:34 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 029351200C7 for <netmod@ietfa.amsl.com>; Wed, 8 May 2019 02:34:31 -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 SXqvfI0JGcma for <netmod@ietfa.amsl.com>; Wed, 8 May 2019 02:34:27 -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 92D881200B4 for <netmod@ietf.org>; Wed, 8 May 2019 02:34:26 -0700 (PDT)
Received: from si0vm1948.rbesz01.com (unknown [139.15.230.188]) by si0vms0217.rbdmz01.com (Postfix) with ESMTPS id 44zWX06Mjvz4f3kZR; Wed, 8 May 2019 11:34:24 +0200 (CEST)
Received: from si0vm02576.rbesz01.com (unknown [10.58.172.176]) by si0vm1948.rbesz01.com (Postfix) with ESMTPS id 44zWX061TSz1Tm; Wed, 8 May 2019 11:34:24 +0200 (CEST)
X-AuditID: 0a3aad0d-15bff700000036fe-75-5cd2a2a08fed
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 si0vm02576.rbesz01.com (SMG Outbound) with SMTP id E2.C6.14078.0A2A2DC5; Wed, 8 May 2019 11:34:24 +0200 (CEST)
Received: from SI-MBX2054.de.bosch.com (unknown [10.3.230.148]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 44zWX04DKDz5fJ; Wed, 8 May 2019 11:34:24 +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; Wed, 8 May 2019 11:34:24 +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; Wed, 8 May 2019 11:34:24 +0200
From: "Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com>
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent
Thread-Index: AdUBk3PTS+EcD5D1QwG4flUjTOYwHwAJx4IAAJhVqNAAFlktgABC8CqQ
Date: Wed, 8 May 2019 09:34:24 +0000
Message-ID: <481f9c0c703c40b79a02a99c73b9be43@etas.com>
References: <941c9e23c3274dcdbca21c22348ca04f@etas.com> <20190503161450.p44lkz6cxzuwjc3d@anna.jacobs.jacobs-university.de> <341a6f3f0dd642f5b2231ac046c40e53@etas.com> <5CD0FD41.2080001@alumni.stanford.edu>
In-Reply-To: <5CD0FD41.2080001@alumni.stanford.edu>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA22Tb0wTdxjH+fXuylF7eD1o+6zAXBqXbOgcylQyzOaLZRpfTFwWY0wTd5WD NtCW9Fq0xhjsRAgqKoHNFhGEatjmBhrpCOpwrfsDmxaLWmZip04nFqMMHYJb1t15YPtiby7f 3/e5z/d57rk7EmM8pI40Wx2c3cqW6+UKXPH2VzlvtLWHDXme9tyC1ss7iYL60NepK2Wr/wyG 8dU+37SsSLZRsaKYKzdXcvY33/lYYaqefL1iXLf1UV8HUYV2auoQSQL9FnTUbqxDCpKhPTI4 F4lh0uEEgsunf8Klw0MEfwV/lEuHcwgO9T5FdSiNlNMrYeDaJ3IxKpM2wNDoZtHOoNfB+T1u magz6Q+h4UwDkvT7cGPAnypqnJ4Pw4cDhKgpejl8OrZ/ptkwgos9h+ViIY3Oh/F46/MgROdA d3cIEzVGa+H6HckHmgbfWckHWg33f/+XkPQrEBm8h0v3L4S2MxNySS+A40fHMKmxCgY8d/AD SONNivUmId4kxJuEtCH8C6ThzXmVlrwlS5cvW2Q3cvy2vMWLNtssp5D0hqhedGmyJIBoEumV 1M+rwgaGYCt5lyWAlpIyvZpS1wtWutFW7DKxvGmT3VnO8XodlT20xsBkvLB5p9Fi5nmzzRpA QGL6TCpyUOCoYta1jbPbJCyAskhcr6VKybUGhi5lHVwZx1Vw9tlqIUnqgWpsE0CVnSvltpaY yx2zZX0OhVJSUhhNciW5rYxMC6B8Uin07hEjKL6CtfDm0hn8JQlnZt0EOojWkufbb7Vg5MBT 8fqk5nYLxuBWm5XTaSnVUSGLFimT0/piGl02FZQNGRh1UiGRGEMRJOwzgwqJgyiFnyIxB1BZ 4upUM2YCWtIhMHR1JsQ/t8Hf37ig+cZeBP2/Ct+aZ2QaA3fTKAEn/eMEVDdNEDA64lNAw56b CuiK186B6Ld+JTQcG1RCZ9ddCi64m9PhmadpLvhPh+dCfMKvgl8OVDFwZMjNwNSJTgZqn11l YP8/YwwEu5vVEA11qGHkQVANV/b1ayAW/04LnfcvaSHc91kWjE79kQOP66Mvx4QVy4QVMzue r9jBOv5nxTNu4tl0VUjZ+15q4ckvWyPXC8qqXuvqX7BJ870zO4LKhm9Vr9/REvzg+Kp034WS 39gr7ifR+a8qby5MKYge2k4dObWr73H3vfzQhq6i3OyPcufUWxorDsonixunll09u9sQu/jw 9hhROF0zb/3uoi3r7rpW7Ntwzblrb2/N9ncfeY3HjLEHRM+8LT/ocd7ELs7F7Dz7H8LA/nKs BAAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/0Bz2so8-wBqlBoC2XrO-zE--0uE>
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: Wed, 08 May 2019 09:34:31 -0000

Thanks Randy for your comments and insights in the history of that management technologies!
Helpful, appreciated!
Albrecht


-----Original Message-----
From: netmod <netmod-bounces@ietf.org>; On Behalf Of Randy Presuhn
Sent: 07 May 2019 05:37
To: netmod@ietf.org
Subject: Re: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent

Hi -

On 5/6/2019 8:24 AM, Schwarz Albrecht (ETAS/ESY1) wrote:
....
> 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).

No.  The concept of "application context" as used in X.701 has no equivalent in the SNMP universe.  It's needed in X.701 because of the decision to permit the negotiation of roles upon establishment of an association.  In fundamentally connectionless SNMP, such negotiation would make no sense.

When the word  "context" is used in the SNMP universe, it refers to a completely different concept, one introduced primarily in order to work around deficiencies in the naming architecture resulting from MIB modules using the SMI.  See, for example, RFC 3415.

> A manager gots normally exclusive access to a specific management 
> application context.

Not true in either the CMIP nor in the SNMP universes.

> Multiple manager usually don't share the same application context

Not true in either the CMIP nor in the SNMP universes, and not true for either meaning of the word "context".

> (due to access conflicts, synchronization issues, etc).

No, that's why, for example, things like VACM and the the TestAndIncr textual convention are used in the SNMP world, and why a rudimentary locking facility has been present in Netconf since the early days.

> That's why the 1:N ratio of management manager to management agent(s).

That's not a realistic assumption for any kind of "industrial-strength" management architecture.

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

I would not rely on X.703 as a source of terminological clarity in this forum.  As an attempt to re-frame CMIP in terms of CORBA-speak, it long post-dates the split between the IETF and ISO/ITU communities.
As for RFC 3413, I think we were abundantly clear that the use of the "sub-roles" was fore purely expository purposes, and that whether there might be any corresponding division within an implementation would be, well, an implementation matter.

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

Consider, for example, aggregating management proxies.
The "disman" MIBS should provide ample examples.

Randy

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