[netconf] ietf-restconf YANG - 'errors' grouping query

"hayden" <hayden@thebrowns.net.nz> Sun, 14 July 2019 21:29 UTC

Return-Path: <hayden@thebrowns.net.nz>
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 5A6F712018A for <netconf@ietfa.amsl.com>; Sun, 14 Jul 2019 14:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 oZKTgPx7C4RR for <netconf@ietfa.amsl.com>; Sun, 14 Jul 2019 14:29:52 -0700 (PDT)
Received: from esmtp06.digiweb.net.nz (esmtp06.digiweb.net.nz [202.174.114.135]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A5412003E for <netconf@ietf.org>; Sun, 14 Jul 2019 14:29:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by esmtp06.digiweb.net.nz (Postfix) with ESMTP id 0F9906235E for <netconf@ietf.org>; Mon, 15 Jul 2019 09:29:49 +1200 (NZST)
Received: from esmtp06.digiweb.net.nz ([127.0.0.1]) by localhost (esmtp06.digiweb.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBbUnhPiavA6 for <netconf@ietf.org>; Mon, 15 Jul 2019 09:29:48 +1200 (NZST)
Received: from email.discountdomains.co.nz (dd-chc-smail01.digiweb.net.nz [202.174.115.190]) by esmtp06.digiweb.net.nz (Postfix) with ESMTP id 652F7623BA for <netconf@ietf.org>; Mon, 15 Jul 2019 09:29:48 +1200 (NZST)
Received: by email.discountdomains.co.nz via HTTP; Mon, 15 Jul 2019 09:29:41 +1200
From: hayden <hayden@thebrowns.net.nz>
To: netconf@ietf.org
Date: Mon, 15 Jul 2019 09:29:41 +1200
Reply-To: hayden@thebrowns.net.nz
Message-ID: <e5c3ad18a35d4d338e4b9cc05e24502f@thebrowns.net.nz>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0eacd67138b24f3b8035da7896069907"
X-Originating-IP: [202.27.34.26]
X-Exim-Id: e5c3ad18a35d4d338e4b9cc05e24502f
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6b1wQcE3KADNKOSQkSIltQ0cE1M>
Subject: [netconf] ietf-restconf YANG - 'errors' grouping query
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: Sun, 14 Jul 2019 21:29:54 -0000

 
  Hi all,
  
 I've been working with the ietf-restconf YANG from RFC 8040 and I had a 
query about the 'error' list definition shown below (I've shortened the 
YANG excerpt for brevity).
  
 -- ietf-restconf@2017-01-26.yang excerpt --

 grouping errors {   description     "A grouping that contains a YANG 
container representing the syntax and      semantics of a YANG Patch error 
report within a response message.";    container errors {     description   
    "Represents an error report returned by the server if        a request 
results in an error.";      list error {       description         "An 
entry containing information about one specific error that occurred         
 while processing a RESTCONF request.";       reference         "RFC 6241, 
Section 4.3.";        leaf error-type { ... }        leaf error-tag { ... } 
       leaf error-app-tag { ... }        leaf error-path { ... }        
leaf error-message { ... }        anydata error-info { ... }     }   } }   

 for context, the 'errors' grouping is used for reporting errors, within 
the yang extension statement 'yang-errors' in ietf-restconf, i.e.

 rc:yang-data yang-errors {   uses errors; }    
 Now, on to my point:
  
 Currently the list 'error' itself omits a config statement, and as there 
is no ancestor with a config-statement, presumably the 'error' list 
represents information that is configuration data.
 My understanding is that according to RFC 7950 (Section 7.8.2), lists 
representing configuration data must have a key specified. The excerpt 
above doesn't specify a key and perhaps should?
  
 Alternatively, another view is that as this is 'error' information, it is 
presumably read-only and perhaps the list or container should be explicitly 
marked as 'config false'?
  
  
 Keen to hear any thoughts on the above. Many thanks in advance.
  
 Kind regards,
 Hayden