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 | [email protected] -----Original Message----- From: Juergen Schoenwaelder <[email protected]> Sent: 03 May 2019 18:15 To: Schwarz Albrecht (ETAS/ESY1) <[email protected]> Cc: Andy Bierman <[email protected]>; NetMod WG <[email protected]> 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
