Re: [netmod] Question on RESTCONF / Yang list creation without key value

Kent Watsen <kent@watsen.net> Thu, 20 June 2019 03:39 UTC

Return-Path: <0100016b72f8144d-4db21faf-b6bc-4519-b63e-bb5a2d139ae4-000000@amazonses.watsen.net>
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 DDCD6120221 for <netmod@ietfa.amsl.com>; Wed, 19 Jun 2019 20:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 TERk0S89j1Cr for <netmod@ietfa.amsl.com>; Wed, 19 Jun 2019 20:39:51 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1081120180 for <netmod@ietf.org>; Wed, 19 Jun 2019 20:39:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1561001989; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=uki+5zb+kyu6dsvpkYJDPkEjJRNpGZ+i8SLms5KPkpE=; b=ha3nEAwZXzwqGqxa+iQyJgNkIfdwBGdWERnCcI9W6P0Kv0VhC+TWFabRO6RFefTF Xw1le9O65ahogvNiXPFm3SeMdhtJdO9sdV2vWdjCHexDKB7K0VmoiG+Tw216enc6LpN j0vOSLGakjKO5h0Z1WXeMY9d7abqCIAPxfLAmwLo=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100016b72f8144d-4db21faf-b6bc-4519-b63e-bb5a2d139ae4-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6AF2869E-A47A-4891-AD71-2DE1638B2FBF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 20 Jun 2019 03:39:49 +0000
In-Reply-To: <b3a90f64-ff17-bed0-01b5-81cd803b840b@cttc.es>
Cc: "netmod@ietf.org" <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>
To: Ramon Casellas <ramon.casellas@cttc.es>
References: <b3a90f64-ff17-bed0-01b5-81cd803b840b@cttc.es>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.20-54.240.8.96
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CkUS5wZx2QZJAV-ypSF9pTvxo24>
Subject: Re: [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: Thu, 20 Jun 2019 03:39:53 -0000


> On Jun 19, 2019, at 2:37 AM, Ramon Casellas <ramon.casellas@cttc.es> wrote:
> 
> 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 ?

The expected answer is "no", because, as RFC 7950 Section 7.8.2 says: '''the "key" statement ... MUST be present if the list represents configuration''', and hence most tooling will expect the keys to be present in POST operations.

That said, note that the requirement is on data-at-rest and not specifically data-on-wire, so there might be wiggle-room for a server-allocated value to be inserted between receiving the POST request and updating <running>. 

However, RFC 8040 Section 4.4.1 says "the message-body MUST contain exactly one instance of the expected data resource.  The data model for the child tree is the subtree, as defined by YANG for the child resource.".  This puts a constraint on the data-on-wire, though the "is" isn't RFC 2119 language and therefore the true meaning could be debated.

Kent // contributor