Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF

Andy Bierman <> Wed, 04 March 2015 23:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 32D2B1A014D for <>; Wed, 4 Mar 2015 15:57:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jVW64RDtAjwx for <>; Wed, 4 Mar 2015 15:57:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 297F61A00C3 for <>; Wed, 4 Mar 2015 15:57:52 -0800 (PST)
Received: by lamq1 with SMTP id q1so24969513lam.0 for <>; Wed, 04 Mar 2015 15:57:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5pw5MJ3OXKPpwcJM3q8MOKOwyFvR7B4r8Cvo6XdeSNI=; b=POeyKc4Dx5UWhn3wFRY35me45CIWZQug7Y66WljQd0LOCf5cpyF9oReFbdb4nMfV3j 77i1+y0JiJVswAm/OWix66f5My3mG3Ag24uam6MiNkME030HJjRSXLFNdidbYpNnpQAS I39cqbgHovQa/jU7wVeKhbPdA5TF9Nam7ZaYYWJpLHTYgnILxNpUvE2Iv1y2gDvAYrfR qcOOjCL12SuqPYjSYnHqorqWWw8/BnlZaynMBF2YuqtfYsXis1w2ALkEfMn+DzbjxTgt d7J3Fm3dYYw3Bd4xuxJJZ2/9qGmIE2Sbr4ALTSOpxDIWupdfO6bW13SlRDD7cfQ0MGDs 7Pbw==
X-Gm-Message-State: ALoCoQnJ3xGaeXedkZ6p02zWtJE96PyR2iWxJIRtazIBOcGhTQLQJ9y3Iw7MkDxm2tmQBeGiVXpR
MIME-Version: 1.0
X-Received: by with SMTP id p9mr5453807laf.123.1425513470576; Wed, 04 Mar 2015 15:57:50 -0800 (PST)
Received: by with HTTP; Wed, 4 Mar 2015 15:57:50 -0800 (PST)
In-Reply-To: <20150304230940.GA68185@elstar.local>
References: <01c301d05538$0b4846c0$21d8d440$> <> <023e01d055fe$8688c9b0$939a5d10$> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local>
Date: Wed, 04 Mar 2015 15:57:50 -0800
Message-ID: <>
From: Andy Bierman <>
To: Juergen Schoenwaelder <>, Jeffrey Haas <>, Susan Hares <>, "" <>, Melinda Shore <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Approved-At: Thu, 05 Mar 2015 04:25:58 -0800
Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2015 23:57:54 -0000

On Wed, Mar 4, 2015 at 3:09 PM, Juergen Schoenwaelder
<> wrote:
> On Wed, Mar 04, 2015 at 02:42:44PM -0500, Jeffrey Haas wrote:
>> There is a presumption that it may be possible for the I2RS agent to
>> restart.  Given that a number of I2RS operations are likely to be built
>> using multiple interactions with the agent, it's necessary to understand
>> what state the agent may be in with regard to last-reset.  A simple but
>> unscalable way to implement this is to preceed each operation with a
>> get/get-config to verify the state of the system prior to sending in the
>> next I2RS operation.
> If this is a problem (which I am not sure), then send a get/get-config
> before each edit operation won't buy you much since the agent can
> still restart inbetween.
>> What is likely more stable is simply knowing whether
>> the system is in the same state as when you last interacted with it.
>> A version numbering system of some sort, whether system-wide or potentially
>> as part of some models (perhaps even just I2RS models) would be sufficient
>> to provide such a checkpoint.
>> An example of the problem space this would address presuming three
>> operations must be completed to accomplish a given I2RS goal, "A B C".
>> If the agent crashes after B has been done, C may either complete with no
>> errors, or may fail before the setup state for A and B are no longer in the
>> system.
> The simple solution is to make "A B C" one atomic edit.

We use entity tags and If-Match in RESTCONF so the client can
be sure it is editing the correct version of the resource instance.
This works nicely for persistent configuration, especially if
the server can reboot with the same config ETags.

If-Match will cause the edit to fail if the server reboots and the
I2RS state is gone.
The client will get a 412 Precondition Failed response and know it might have to
start over.

RESTCONF only requires the server to maintain an ETag for the config root.
Finer granularity (e.g., the parent resource has an ETag) is probably needed
to support multiple concurrent edits.

>> An analogous mechanism in SNMP to address such issues are discontinuity
>> objects.
> No, not really. Discontinuity objects help with monitoring, not so
> much with sets. SNMP folks invented TestAndIncr (RFC 2579), which is
> used to implement so called spin-lock objects. While this can be made
> to work, I am not sure I would recommend this approach. While this
> method allows to detect that edits were conflicting, it makes the
> clients responsible to clean up the mess.
> /js


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <>
> _______________________________________________
> i2rs mailing list