Hello Andy, Juergen, I got a side question for clarification (which was perhaps already discussed years ago on the list, but I'm just starting to follow NETCONF & NETMOD activities):
The management paradigm and management association is related to roles (Management) Manager (or Master) and (Management) Agents, in an hierarchical relationship of 1:N concerning the ratio of Manager to Agents. That's the usual case, being aware of the exceptional cases with e.g. M:N (or additional, interim Management Broker, Gateway, etc entities). I would have expected that - the Management Data Modeling language (YANG), - the Management Datastore Architecture (RFC 8342), - a Network Configuration Access Control Model (RFC 8341) and even - Network Management Protocols for YANG data (such as NETCONF, RESTCONF) use the role model of Manager and Agent. However, I do see only the role relationship Client/Server (in that RFCs), hm? 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. 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. Does anyone know the motivation, background? Thanks, Albrecht 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: netmod <[email protected]> On Behalf Of Juergen Schoenwaelder Sent: 03 May 2019 11:20 To: Andy Bierman <[email protected]> Cc: NetMod WG <[email protected]> Subject: Re: [netmod] validating a YANG action On Fri, May 03, 2019 at 01:10:58AM -0700, Andy Bierman wrote: > On Thu, May 2, 2019 at 10:57 PM Juergen Schoenwaelder < > [email protected]> wrote: > > > On Thu, May 02, 2019 at 04:15:28PM -0700, Andy Bierman wrote: > > > Hi, > > > > > > The text about invoking actions in RFC 7950, sec. 7.15 is not > > > clear about whether the ancestor data nodes have to exist. > > > > > > sec 7.15.2, para 2: > > > > > > The <action> element contains a hierarchy of nodes that > > > identifies the node in the datastore. > > > > > > > > > The RFC does not say anything about if the data node is required > > > to exist or not. There is no distinction between NP-container, > > > P-container, or list which are ancestors of the action node. It > > > does not specify which datastore, and that is not supplied in the > > > <action> RPC. > > > The text specifies what must be in the <rpc> request, not in any > > datastore > > > or state data. > > > > > > It seems like the intent is that no instance test is specified at > > > all and the corresponding ancestor nodes to the action node do not > > > have to exist for the action to be invoked. (The action may succeed or > > > fail). > > > The issue is whether there is an existence-test before invoking > > > the > > action. > > > > We discussed actions during the work on NMDA. RFC 8342 has this text > > in section 6, in particular 6.1 says: > > > > Actions are always invoked in the context of the operational state > > datastore. The node for which the action is invoked MUST exist in > > the operational state datastore. > > > > > This only applies to a server implementing NMDA. > There is no requirement for a server implementing RFC 7950 to make > this test. > Yes, the behavior is unspecified in RFC 7950. However, note that RFC 8342 formally updates RFC 7950 and the Introduction section says: This document updates RFC 7950 by refining the definition of the accessible tree for some XML Path Language (XPath) context (see Section 6.1) and the invocation context of operations (see Section 6.2). This update may not affect your implementation but since you asked whether there is an existence-test before invoking the action, I thought a pointer to RFC 8342 is perhaps relevant. /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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
