[netmod] Question on RESTCONF / Yang list creation without key value
Ramon Casellas <ramon.casellas@cttc.es> Wed, 19 June 2019 06:38 UTC
Return-Path: <ramon.casellas@cttc.es>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EE2120128 for <netmod@ietfa.amsl.com>; Tue, 18 Jun 2019 23:38:21 -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 EDYn1vcShwSX for <netmod@ietfa.amsl.com>; Tue, 18 Jun 2019 23:38:18 -0700 (PDT)
Received: from mx01.puc.rediris.es (outbound2mad.lav.puc.rediris.es [130.206.19.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139D6120336 for <netmod@ietf.org>; Tue, 18 Jun 2019 23:38:17 -0700 (PDT)
Received: from leo.cttc.es (leo.cttc.es [84.88.62.208]) by mx01.puc.rediris.es with ESMTP id x5J6bPMd023423-x5J6bPMf023423 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=CAFAIL); Wed, 19 Jun 2019 08:37:27 +0200
Received: from [84.88.61.115] (pcdhcp61-115.cttc.es [84.88.61.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo.cttc.es (Postfix) with ESMTPSA id C8CCA1FEF8; Wed, 19 Jun 2019 08:37:25 +0200 (CEST)
To: netmod@ietf.org, ARTURO MAYORAL LOPEZ DE LERMA <arturo.mayoral.ext@telefonica.com>, Italo Busi <Italo.Busi@huawei.com>, "Sethuraman, Karthik" <karthik.sethuraman@necam.com>
From: Ramon Casellas <ramon.casellas@cttc.es>
Message-ID: <b3a90f64-ff17-bed0-01b5-81cd803b840b@cttc.es>
Date: Wed, 19 Jun 2019 08:37:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cw8jHfjKJh4VbIy1sPGIG9isQMU>
Subject: [netmod] Question on RESTCONF / Yang list creation without key value
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 06:38:22 -0000
Dear all, Apologies if this is a FAQ, or a basic question but we have been recently involved in using RESTCONF / YANG as a controller NBI to request optical connections in the photonic media layer within the TAPI framework and we have a doubt. TL&DR: is it possible to create a list entry without specifying its key, assuming that the server can allocate such key while processing the request ? For the context, the TAPI connectivity model allows a client to request a connectivity-service. Assume the server manages a list of connectivity-services (within a context) keyed by a UUID. grouping connectivity-context { list connectivity-service { key 'uuid'; uses connectivity-service; } } with grouping connectivity-service { list end-point { key 'local-id'; min-elements 2; uses connectivity-service-end-point; } leaf uuid { type uuid; } For historical reasons, there are two flavors: one is RPC based and the other one is data node based. In the RPC based approach, the RPC method allows the client to specify the endpoints, the server creates the service and replies with the details. rpc create-connectivity-service { input { list end-point { key 'local-id'; min-elements 2; uses connectivity-service-end-point; } ... output { container service { uses connectivity-service; } } } When considering deprecating the RPCs and moving towards a plain POST, we want to know if the client MAY not specify a uuid, as in POST to http://localhost:4900/restconf/data/tapi-common:context/tapi-connectivity:connectivity-context { "tapi-connectivity:connectivity-service" : [ { "end-point" : [ { ... }, A particular use case is as follows: The client MAY specify a uuid when requesting a connectivity service - The server MUST allocate a uuid upon creation of the list entry - If the client provided uuid can be used, the server MUST use that UUID (provided there are no conflicts, other errors, etc) - If such uuid is already in use, the server MUST reply with a failure (in-use, 409) or similar. The client MAY retry the operation with another client generated UUID. - If the operation is successful the server MUST reply with the Location header It seems this case is somehow covered by the RPC, but when a new connectivity-service resource is requested through the RESTCONF Data API through a POST operation, MUST the client specify the key (uuid) or is it legal to allow the server to process the request, allocate the uuid in the process and return the location header?. It is assumed that the server has all the information needed to allocate a uuid. As per RFC7950 The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. Any "mandatory" statements in the key leafs are ignored. A leaf that is part of the key can be of any built-in or derived type. All key leafs in a list MUST have the same value for their "config" as the list itself. It does not explicitly say "by the client", but it can be inferred. Different views are i) the server may allocate the uuid, [ as in https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5: If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30) ] ensuring unique leys or ii) the uuid must be provided by the client We are also aware that with NETCONF things can be different (7.8.6. NETCONF <edit-config> Operations List entries can be created, deleted, replaced, and modified through <edit-config>, by using the "operation" attribute in the list's XML element. In each case, the values of all keys are used to uniquely identify a list entry. If all keys are not specified for a list entry, a "missing-element" error is returned.) Thank you very much in advance Ramon
- [netmod] Question on RESTCONF / Yang list creatio… Ramon Casellas
- Re: [netmod] Question on RESTCONF / Yang list cre… Kent Watsen
- Re: [netmod] Question on RESTCONF / Yang list cre… Ramon Casellas