[netconf] restconf 'get' on non-presence container

Kent Watsen <kent+ietf@watsen.net> Fri, 21 June 2019 14:42 UTC

Return-Path: <0100016b7a7ca57b-bedf88a1-e867-4d0d-a44a-94964a93ccbb-000000@amazonses.watsen.net>
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 1CD5112027B for <netconf@ietfa.amsl.com>; Fri, 21 Jun 2019 07:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_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 VvtRRMkR4OHE for <netconf@ietfa.amsl.com>; Fri, 21 Jun 2019 07:41:59 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D134120114 for <netconf@ietf.org>; Fri, 21 Jun 2019 07:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1561128117; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=fyXuFMKfYXEISRIZf52te0Qn719bxWrQZop55MYdTqQ=; b=HyF9CInF0klD6JFSzJyuDv05zrUhJySl21mL4wOQ08nwfEBwOTzPlHhQJlBM0x9z CC42edKtgSFO0OBdsZ0mx/p6ocXgHPVuVf9bm2MIK7UsXXmpKxxno5kawdGiNpzuWEY 034SQOtxxUEjZqKsmwmbJ87lhUyFeHuoJ+mNoeNE=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <0100016b7a7ca57b-bedf88a1-e867-4d0d-a44a-94964a93ccbb-000000@email.amazonses.com>
Date: Fri, 21 Jun 2019 14:41:57 +0000
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.06.21-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/m2CN-W5gDL4jvJkho1xAAdtbirg>
Subject: [netconf] restconf 'get' on non-presence container
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: Fri, 21 Jun 2019 14:42:01 -0000

Given:

  module foo {
    ...
    container widgets {   <--- NOT a presence container
      list widget {
        ...
      }
    }
  }

Assuming no widgets have been configured, would a GET on "/foo:widgets"
return:

    1) 200 with an empty response (i.e., <widgets xmlns="..."/>
    2) 404 (Not Found)
    3) It's up to the implementation


With NETCONF, or RESTCONF when retrieving an ancestor of an 
NP-container, it's clear that RFC 7950, Section 7.5.7 (XML
Encoding Rules) comes into play:

   If a non-presence container does not have any child nodes, the
   container may or may not be present in the XML encoding.

However, this question regards the GET being on the NP-container itself.
That is, it's not an encoding question so much as a protocol question.
RFC 8040 doesn't discuss this directly, but Section 4.3 (GET) says:

   If a retrieval request for a data resource represents an instance
   that does not exist, then an error response containing a "404 Not
   Found" status-line MUST be returned by the server.

Okay, so it does the NP-container "exist" or not?  RFC 7950, Section 
7.5.1 (Containers with Presence) says:

   ...the [non-presence] container has no meaning of its own, existing
   only to contain child nodes.  In particular, the presence of the
   container node with no child nodes is semantically equivalent to the
   absence of the container node.


Kent