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

Randy Presuhn <> Tue, 07 May 2019 03:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EB4E120020 for <>; Mon, 6 May 2019 20:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RyEmQGVY6N9t for <>; Mon, 6 May 2019 20:36:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79181120006 for <>; Mon, 6 May 2019 20:36:33 -0700 (PDT)
Received: by with SMTP id h17so1554720pgv.0 for <>; Mon, 06 May 2019 20:36:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Aapn8+q/lSXTcd/BIYJDAxk9pWzjem0Uwpgh40cgHTU=; b=lB8ZmeAUF4Pkhkc91KIrMuYgvW57m+Z8Kra7OGjQjES2NZloa7zSw4S8AqekA9Ekfh m7k7TBMbZ1w3s+Z+s3bzkYV6g2AJzNCXjtG+IU5nmWiXfJJlydrbjd3413on2N2K8bC2 nSNyOiuqskSlAzisn/J4e1D4cvcGVcS9/JiJZxcY+OkFuVwH3+PtKIQoodUNbX+Wg8Xs +6lJ53h9j6ixCiOQJpBRrm5/byPQpro5q2l7LC/qbjpHkCjq8qiEQMJfIDrcFDefEyhK J/GqYA97A1B9Idc+bWw2cPYW2eEBiNAh/gx/x2ksd7W3xuQE9aCIBzFcJ5Szd8RQ7m/U jRxQ==
X-Gm-Message-State: APjAAAUyMxYBdxn9txYq1gAGoEXZUCL6BqSpTjS96qgFBfnCGGP+xblY /vNQ9oweZQLZMpxl2FxKfIXf1VU0r70=
X-Google-Smtp-Source: APXvYqxj1+HOgP9n17vbDaOZmpqetQvpIQ7DHZkyED865LXdfQuz6p8VcYYttZbt4PrM0Q6ka+od1A==
X-Received: by 2002:a63:42:: with SMTP id 63mr37109675pga.337.1557200192544; Mon, 06 May 2019 20:36:32 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a26sm20054127pfl.177.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 20:36:31 -0700 (PDT)
References: <> <> <>
From: Randy Presuhn <>
Message-ID: <>
Date: Mon, 6 May 2019 20:36:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] Management Protocol Roles: Client/Server vs Manager/Agent
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 May 2019 03:36:36 -0000

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.