IETF Logo Mail Archive

Re: [netconf] RFC8040 inquiries

Anton Snitser <antons@sedonasys.com> Mon, 07 October 2019 12:37 UTC

Return-Path: <antons@sedonasys.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 B9DE6120099 for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 05:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sedonasys.onmicrosoft.com
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 hRJozY2IG-ia for <netconf@ietfa.amsl.com>; Mon, 7 Oct 2019 05:37:45 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60092.outbound.protection.outlook.com [40.107.6.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36E7120018 for <netconf@ietf.org>; Mon, 7 Oct 2019 05:37:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VKUB9ePXvEk5ALaZluvv/KIhXI+YHHbJ21XueTPXI2hazZC9sb5/oKLB+EcBs7ZMRE2BOT2+YK2DV0DndNRNfkCDPszqDXImgtfFlB4ggUFPJfgwBFO8lmwiORJ2ieH9odcjQMvHzpUZwQj6/qWEp7it0fMgg2b6qVBJDVItY86t2feFCXPXUghnuNyRTnnEcpg0IBOBmtkPICbtKRedGpZkhyAy4eR2btUii8ZmVr3s4D2bhadAqWiq2CEaFqiFf5GD1nm1+L8WuRsVNppp0rp8/v9ooIVVNbliUqGhZNDISPT8WTOuWPL6a/YVS0gphBw/n3zrtfuPUfd48s8YYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1AqVmAi8EuajfSndb4FNbW/yZoaWdi0BBGvo1MJkH3o=; b=moVch4PjDDQszZoRARRpeI6S1tIbqyA9xO/SP2rkIVJ4aVLvF+MAdazHC7h3+SJmXR+Ihg3aguKU8Dly05b1oO1VtAjgtjXGDiKYSUJ35mVGGLkfBEZKnNbXGv2/r3A5bRkWrd3E2A8x0EVCR5MfinPoS05/g/5AYZb/XtQWUgfL0YXwVmMyLXQmlZtOyqRcosCYa+wtoOm5mbZ0FPI3Q9W9bDVya7Ce92eFuEZiRndktEir/XVh2ZJl0UrcVC60GbyxxiHw7xFuMOgP8aMPSItxEAWpjlipZ6DbQsLhLIEQtqsErdLrgGaZgMUsanIbgZUmXiYnCNVNZBUMqTJOgQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sedonasys.com; dmarc=pass action=none header.from=sedonasys.com; dkim=pass header.d=sedonasys.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sedonasys.onmicrosoft.com; s=selector2-sedonasys-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1AqVmAi8EuajfSndb4FNbW/yZoaWdi0BBGvo1MJkH3o=; b=hd1ey4CmjLG2Rjw+r5WBDljnbRF4HTi60lihIgGMyP6O536fi8Ao2l67ZNEpj/e2MDWbS9Tj+Ahr9Y45rBE8CjiD7hm7ZGzAuzKhh/hIRZLQiSp0Dh41GIABvh4xcRyg/Cop773o2x71aMgMQYaMQrVHy9VC0duxSKc4G1UbyYM=
Received: from DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM (10.255.17.204) by DB8PR10MB2731.EURPRD10.PROD.OUTLOOK.COM (20.179.9.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Mon, 7 Oct 2019 12:37:42 +0000
Received: from DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM ([fe80::f97f:fdcb:cd01:c7b5]) by DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM ([fe80::f97f:fdcb:cd01:c7b5%7]) with mapi id 15.20.2327.023; Mon, 7 Oct 2019 12:37:42 +0000
From: Anton Snitser <antons@sedonasys.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "andy@yumaworks.com" <andy@yumaworks.com>, "kwatsen@juniper.net" <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>, Liviu Cohen <liviuc@sedonasys.com>
Thread-Topic: RFC8040 inquiries
Thread-Index: AQHVePX19zmZMGveE0a2YmIbFCjzPadPNFAA///tToCAACYBgA==
Date: Mon, 07 Oct 2019 12:37:42 +0000
Message-ID: <4CD91E36-288A-44B5-A1DA-64A943DB97AF@sedonasys.com>
References: <DCDA4768-5366-4D1B-88CC-0F60333591A3@sedonasys.com> <85070ED8-38A7-4C0D-B9C5-BC53252AB800@sedonasys.com> <20191007.142139.1024121209074847392.mbj@tail-f.com>
In-Reply-To: <20191007.142139.1024121209074847392.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=antons@sedonasys.com;
x-originating-ip: [37.142.40.85]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a1f4c4ac-71d6-4884-b7b0-08d74b2325a1
x-ms-traffictypediagnostic: DB8PR10MB2731:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB8PR10MB2731DD9B6CB1D9CC321D1E48D79B0@DB8PR10MB2731.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01834E39B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39830400003)(136003)(346002)(366004)(396003)(189003)(199004)(53754006)(555904003)(6246003)(6506007)(4326008)(76176011)(107886003)(54906003)(102836004)(6306002)(6512007)(14454004)(508600001)(7116003)(45080400002)(36756003)(33656002)(5660300002)(8936002)(71190400001)(71200400001)(8676002)(81156014)(6916009)(81166006)(316002)(76116006)(7736002)(99286004)(66066001)(305945005)(91956017)(26005)(186003)(25786009)(2906002)(86362001)(3846002)(6116002)(6486002)(2616005)(476003)(486006)(11346002)(446003)(66556008)(64756008)(66446008)(256004)(66946007)(229853002)(66476007)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB8PR10MB2731; H:DB8PR10MB3387.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: sedonasys.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qtxmUoNRHyowseeSJUIqKsPllKCpvwlfT6Ul+uA5iS6U5+F/WmuG8ft6sW1sU3ZLm5lH784hKBS1n+WZrzl6ZZ2VZ74/VHKqh8Ll+bEMPoXKxUUdxB8KGKVhgPdEvtQRTzUSy0h+Ifbno/MPL0ch/EvcoGtmGTQrr9aBxCD3pbN0pOpTBRJm1or5d+Q15dow9MopNY6VrpUPq3g2fERZtHICIdtAew3HFsjhTcF1OjJXemSuOaq99eacoyYmgVCwlnZSXno2t9M1d6rYj4Yejl0G6rMwYKaFcg3sdlrBsKKv4QejYZAV3YrsARHazmSSK97hXDhbQCX4bTb92miNs/T4uifrXTlsX771vough5OVErwmgWu5OEYLlPRvXbk6BuTPkw1EjsUUaroDvpjow55iLFQ6hsNv0emO4pDlKLFj3sIVhIwfO0tI4r4FhOEYKN9xhtM9WrPuyGeF61QHxg==
Content-Type: text/plain; charset="utf-8"
Content-ID: <E85F9C91724F5A4BB5428631354E8A4D@EURPRD10.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sedonasys.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a1f4c4ac-71d6-4884-b7b0-08d74b2325a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2019 12:37:42.2728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d7c5624d-c76e-473e-9a79-91d374431ce8
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FXDMfptSTfs2+QO1ihKvgHe1FFzUyvnacQbNLXpLgbM62zr7LWCN7mpzZ/wznmM9VQWF87fGZF1kqWqkpLBk8g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR10MB2731
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/v8xojoogIN1keQEMPifP_tqld0s>
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:37:47 -0000

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?

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/>
    >

v2.23.0 | Report a Bug | By Email