Re: [netmod] Action and RPC statements

Andy Bierman <> Wed, 01 November 2017 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3E5A13F70A for <>; Wed, 1 Nov 2017 09:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xFyKMoGluovI for <>; Wed, 1 Nov 2017 09:44:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A22F113F7D7 for <>; Wed, 1 Nov 2017 09:44:47 -0700 (PDT)
Received: by with SMTP id a132so3224030lfa.7 for <>; Wed, 01 Nov 2017 09:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HpwkEkzzMmvzwCT2mocnThFI5E4kmoMe/hszpymXMxg=; b=vgVLwicb/6jPKgMs9knEA23H1zDLHeGbMP2U4AKLiIhwKecF2OkVDb8ZFIKRQWgmsY amgwkGrBBGrVhaphxeO/vCGMRskEGfyqydq19YnyZY12iTYKc9KVQBTPzArOzc/BSR6l mjRNWv6mge5895KgTAd+98MRQAlvON8ocvVGVbXJfT8Dssrzox+bLFLSl6xKhTaYI5wi gEmiuqvy6+q01ZZLwAn5f5/O0NeCEjSdMVdPLGbdMMHElcCoxLv4TpKZ+/XRmKO88l/k g0tch/Md4L25oYrnuiktIVE2TOX3CiEKTG8srjQpAzWjexmRj4pwESIhBwAnmE1oo68K CdoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HpwkEkzzMmvzwCT2mocnThFI5E4kmoMe/hszpymXMxg=; b=Co3G8lAmUzEitbrcfyWPM4LOTWcRP3dw8ZIQEn7TXnPxSD78UN8AS95Mx09TpyRvQr E9Olvsy6F38mN+9tonrv9bkdZH90PkWg8sbb2NeNZCmCfuRf1z2SUT4orReVw8uWH0nT vrJWmazJlM9xy2mzlXJaKZQdsVwFHzaWFuqydfgg1fWjVNAxW4ff4kdq6FzxLRklqTny hFZJyst4Dm3clLR2+yhdciqvNJNT6rAK7OapYGapCjwp5HjRt8R8gZ6R4aTfNCu7tw1N XdyXrKCT9acfUTtoGWlqRxgAJtNO5ofyeQB9TwhdAjg52N5UEoiAsLQeVOXGxItmHECE FJAA==
X-Gm-Message-State: AJaThX42oU2kkyjJUghX8uSxMllhHOeXDYhHgBAd0g1g5feglAGlHN5e AXQJ05eclP6SRCZAwLum10LNjIRHyz5UhF/Z25ExsA==
X-Google-Smtp-Source: ABhQp+TKJE+kvxvNYYSelieG3lxHH6SSHtoNp5JukAcTfjRhkV82nBxEDtxWfUvKTGU8vPX8iIq+qg6DrgVTvlhjsQc=
X-Received: by with SMTP id k192mr146719lfe.45.1509554685917; Wed, 01 Nov 2017 09:44:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 1 Nov 2017 09:44:44 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Andy Bierman <>
Date: Wed, 1 Nov 2017 09:44:44 -0700
Message-ID: <>
To: Phil Shafer <>
Cc: Robert Wilton <>, Kent Watsen <>, Martin Bjorklund <>, "" <>, Randy Presuhn <>
Content-Type: multipart/alternative; boundary="001a11411b0ad2d58d055cee96cb"
Archived-At: <>
Subject: Re: [netmod] Action and RPC statements
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Nov 2017 16:44:56 -0000


So a server will be required to guess the correct datastore until it
finds the right one that matches the action instance?


The server will guess the datastore in some proprietary order and parse
instances of /top/ and /top/list1.  Then it finds the <do-test> action
and parses the input to get to the datastore and find out the real datastore
to use.  If the server guessed wrong, then it reparses the <action> against
the requested datastore.  Hopefully the schema trees match up.

Will vendors do all the extra work required to support this sort of thing?
I doubt it.


On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer <> wrote:

> Robert Wilton writes:
> >ii) However, as far as I can see, it doesn't make sense for an action to
> >directly affect the contents of any configuration datastore, that should
> >be done via a purpose built rpc (like edit-config).
> An example action would be to retrieve the  fingerprint of an ssh
> key.  I might want to get the fingerprint of a key in <candidate>
> before I commit it.
> Or I could have an action that sets the SNMPv3 auth key to a random
> value, and I want to invoke that action against <candidate>.
> Seems like <startup> might also be an interesting place to target
> actions, but I can't think of a good example.
> There are always scenarios where something is useful, and the problem
> with ruling it out is that it becomes needed at some later point.
> We've a habit of ruling out things and later wishing we had them.
> Is the easy fix to just put a datastore leaf under rpc/action and
> have it default to operational?  Any specific RPC can define its
> own datastore leaf of hard-code the database in the description
> (explicitly or implicitly <operational>), but the <action> RPC only
> gets this if we make a new parameter for it.
> Thanks,
>  Phil