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

Andy Bierman <andy@yumaworks.com> Fri, 06 March 2015 18:08 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E63D1A1B1D for <secdir@ietfa.amsl.com>; Fri, 6 Mar 2015 10:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YatANgaghAhh for <secdir@ietfa.amsl.com>; Fri, 6 Mar 2015 10:08:48 -0800 (PST)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0FA1A1AB8 for <secdir@ietf.org>; Fri, 6 Mar 2015 10:08:47 -0800 (PST)
Received: by lamq1 with SMTP id q1so36149322lam.0 for <secdir@ietf.org>; Fri, 06 Mar 2015 10:08:46 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nh4e4MkBAarfS5f48ruhyDMEkdHN1Li/m2Wh6ty0nbo=; b=Rmf9pEHTfZmaoKxSJ9vhZM5p0LHI+pzfGtTt39W+mBHIulnUnrqkkupWiDjwyvgIS1 QSgfrk7eQoUwffMxqRkAhk06K8X2bxkRIqiV4B/1jcfedf1wCKBI4oiJrakIEbiIIK3O jg1Cc8HE4IPS8Kbdl3QEdfbjtrEXd+zErlHWR59sEdh3KRwOuKTZPZA7doPCVFKJtDNW cU43NBZjmTsHJKTbaw/1yOaQCFCKeaMp8pAr09On9dgHzEXyt2ZXJOaCFzlDTbguhkS9 ZtAIQT+lXpRyNo6K/Ie0guj932V1EKTQA2fFHCGrdwb+YzHZh4NkQEFUrYG/S9HRYMyf hSNA==
X-Gm-Message-State: ALoCoQlaRRRpDHTJUTMhrnRyCLPZlsgiisBE/91J5oSJoP5izZ1IGUF4GjnrPhPVniNCR9+nt384
MIME-Version: 1.0
X-Received: by 10.112.139.136 with SMTP id qy8mr14183317lbb.38.1425665326056; Fri, 06 Mar 2015 10:08:46 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 6 Mar 2015 10:08:45 -0800 (PST)
In-Reply-To: <20150306180434.GA10092@pfrc>
References: <01c301d05538$0b4846c0$21d8d440$@ndzh.com> <54F4E7D7.1000603@gmail.com> <023e01d055fe$8688c9b0$939a5d10$@ndzh.com> <20150304194244.GB9142@pfrc> <20150304230940.GA68185@elstar.local> <CABCOCHS2hZMFymCa=Of2iDPUiwcLwyKQsmciaYqCcyON7ks07g@mail.gmail.com> <20150305081801.GA68988@elstar.local> <20150306180434.GA10092@pfrc>
Date: Fri, 6 Mar 2015 10:08:45 -0800
Message-ID: <CABCOCHQWe=+SKgtPW+OU3UtSd0uWghAjAoJkhESPwEgCtzyQbA@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/_FZRN1qab03O5QOAcHnHlVs2MTk>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, Susan Hares <shares@ndzh.com>, secdir@ietf.org
Subject: Re: [secdir] [i2rs] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2015 18:08:56 -0000

On Fri, Mar 6, 2015 at 10:04 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Thu, Mar 05, 2015 at 09:18:02AM +0100, Juergen Schoenwaelder wrote:
>> On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote:
>> > > 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.
>> >
>>
>> Thanks, this all makes sense. So there is a viable mechanism to create
>> a sequence of linked edits. The main trade-off, however, between a
>> single atomic edit and a sequence of linked edits is who is taking the
>> pain to cleanup the mess if things fail in the middle. If you write a
>> client, you love the server to do it. If you write a server, you love
>> the client to do it. ;-)
>
> It's all pain, but some component has to deal with it.
>
> I'm glad that restconf seems to have this situation covered, Andy.  Is there
> a similar mechanism in netconf that I've missed?  If so, this completely
> deals with the need for i2rs to have to ask for anything new. :-)
>

NETCONF has no support at all for this sort of thing.

> -- Jeff

Andy