Re: [netconf] RFC8040 inquiries

Martin Bjorklund <mbj@tail-f.com> Mon, 07 October 2019 12:47 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82225120020 for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 05:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 N9Xg2pSxZJ69 for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 05:46:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 89E46120018 for <netconf@ietf.org>; Mon, 7 Oct 2019 05:46:58 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id CCC9E1AE018A; Mon, 7 Oct 2019 14:46:56 +0200 (CEST)
Date: Mon, 07 Oct 2019 14:46:31 +0200
Message-Id: <20191007.144631.660053512553089069.mbj@tail-f.com>
To: antons@sedonasys.com
Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf@ietf.org, liviuc@sedonasys.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4CD91E36-288A-44B5-A1DA-64A943DB97AF@sedonasys.com>
References: <85070ED8-38A7-4C0D-B9C5-BC53252AB800@sedonasys.com> <20191007.142139.1024121209074847392.mbj@tail-f.com> <4CD91E36-288A-44B5-A1DA-64A943DB97AF@sedonasys.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/fpm3dqNkqKRBvgslij2mACvkGY0>
Subject: Re: [netconf] RFC8040 inquiries
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 12:47:01 -0000

Hi,

Anton Snitser <antons@sedonasys.com> wrote:
> Hello Martin,
> 
> Thank you for the reply..
> 
> Yes. This is exactly what I mean by sync/async. At the moment we reply
> with a 201 when the resource is applied/created on the network devices
> as to remain in sync with the network state. I want to understand
> whether the decision to do one approach or the other is a MUST to be
> compliant or left to the implementor at the implementation stage?
> 
> To make my question simpler, is there are definitive one way? Or both
> are valid?

At the moment, this is not defined in any RFC, which means that both
behaviours are ok.

When we did the NDMA, there were some discussions around this (e.g.,
adding a parameter to let the client control the behaviour), but
nothing has been done.  However, with the NMDA, the client can at
least detect if a certain piece of config has been applied, but
checking the value of the config node in <operational>.


/martin


> 
> Again, I appreciate you taking the time to answer.
> 
> Best regards
> 
> On 07/10/2019, 15:22, "Martin Bjorklund" <mbj@tail-f.com> wrote:
> 
>     Hi,
>     
>     Anton Snitser <antons@sedonasys.com> wrote:
>     > Hello Everyone,
>     > 
>     > My name Is Anton Snizar, I am a System engineer working for Sedona
>     > Systems.
>     > 
>     > I have a foundational question regarding the RESTCONF specification. I
>     > have not seen anywhere in the document whether it is required to
>     > provide a synchronous or asynchronous interface? Or maybe you have
>     > left it for the implementor to decide?
>     > 
>     > For Non-NMDA (unified datastore) RESTCONF (RFC 8040) it is stated that
>     > only a 201 created status code will valid to be used when new objects
>     > are created/configured. With that in mind, should one treat this as an
>     > implicit definition to make the interface synchronous? E.g., only upon
>     > resource creation in the network will a 201 be sent to the NBI client?
>     
>     It depends on what you mean with synchronous.  An implementation may
>     write the new resource to its internal db and then reply with 201.
>     But that doesn't mean that the new resource is "used" or "applied" at
>     that point in time, so in that sense it can be viewed as
>     asynchronous.  Some other implementation might not return 201 until
>     the resource is really applied.
>     
>     
>     /martin
>     
>     
>     
>     > At the moment we implement a synchronous RESTCONF interface but at the
>     > same time wondering support for async for some optimization
>     > considerations. As were wondering whether it would still be compliant
>     > to the standard or not.. Any clarification would be helpful.
>     > 
>     > Hanks,
>     > Best regards
>     > 
>     > [id:image001.png@01D3D4EC.AFD81260]
>     > Anton Snizar | Systems Engineer

>     > m: +972-504042744
>     > e: antons@sedonasys.com<mailto:antons@sedonasys.com>
>     > w: sedonasys.com<https://sedonasys.com/>
>     > l: Linkedin<http://linkedin.com/in/anton-snizar-4aa57646/>
>     > 
>     
>