Thanks Randy for your comments and insights in the history of that management technologies! Helpful, appreciated! Albrecht
-----Original Message----- From: netmod <netmod-boun...@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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
