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

[Randy Presuhn <[e-mail]>]

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