[netconf] RFC6241: "xs:QName" text values in <nc:rpc-error> instances

Jernej Tuljak <jernej.tuljak@mg-soft.si> Thu, 01 June 2023 09:13 UTC

Return-Path: <jernej.tuljak@mg-soft.si>
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 84004C151087 for <netconf@ietfa.amsl.com>; Thu, 1 Jun 2023 02:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeOOQcTA_ss9 for <netconf@ietfa.amsl.com>; Thu, 1 Jun 2023 02:13:34 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id A9A2CC14CE45 for <netconf@ietf.org>; Thu, 1 Jun 2023 02:13:31 -0700 (PDT)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 95E92C41D787 for <netconf@ietf.org>; Thu, 1 Jun 2023 11:13:29 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 galileo.mg-soft.si 95E92C41D787
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1685610809; bh=3yLAoixTAnyEO1cugo9iVzjEJl/b4GhYxjNqgD6bqbQ=; h=Date:To:From:Subject:From; b=LWC8pl9WSKlicsvxID1JOLAB11k2LRt6rNXyMK5w7l+Lxsg/3tKZoB0N9VAoYgany pSKe4LedLinckyvd5xCtsC8R9UahnifxDuzWXFZiPBWH2MCFi7sJcLd1iqhfH3V/jo AZVf5nabi/rx0w+vZxwxe/ujPaRYxXWqeRkzmPI8Zt+yqopiez0bOK8WPugQBXkTDH ajnPI3L6c3wBN8BiwmqPUBmPsgPf2llpXY7W8TU2vcFn+HNPbwyNFq6/pXeyl/cAqg rNOvoTOuVcEyJIxciJo4eNf16gt4zz8OK8bfCP1IpZeQX2SwZd6xhltI5ZLtJ1Otl3 kKJ3PutU0K/dQ==
Message-ID: <59252a86-3889-16e8-5542-e12790958b94@mg-soft.si>
Date: Thu, 01 Jun 2023 11:13:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: Netconf <netconf@ietf.org>
From: Jernej Tuljak <jernej.tuljak@mg-soft.si>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/c-D7FfFEZ6SbIQLLMsaXB93H1wQ>
Subject: [netconf] RFC6241: "xs:QName" text values in <nc:rpc-error> instances
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 01 Jun 2023 09:13:38 -0000

Hi,

RFC 6241 contains the following example in section 4.3.

    Example:  An error is returned if an <rpc> element is received
       without a "message-id" attribute.  Note that only in this case is
       it acceptable for the NETCONF peer to omit the "message-id"
       attribute in the <rpc-reply> element.

      <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
          <source>
            <running/>
          </source>
        </get-config>
      </rpc>

      <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <rpc-error>
          <error-type>rpc</error-type>
          <error-tag>missing-attribute</error-tag>
          <error-severity>error</error-severity>
          <error-info>
            <bad-attribute>message-id</bad-attribute>
            <bad-element>rpc</bad-element>
          </error-info>
        </rpc-error>
      </rpc-reply>

I think this <rpc-reply> is semantically incorrect. It should be 
corrected to:

      <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <nc:rpc-error>
          <nc:error-type>rpc</nc:error-type>
          <nc:error-tag>missing-attribute</nc:error-tag>
          <nc:error-severity>error</nc:error-severity>
          <nc:error-info>
<nc:bad-attribute>message-id</nc:bad-attribute>
            <nc:bad-element>nc:rpc</nc:bad-element>
          </nc:error-info>
        </nc:rpc-error>
      </nc:rpc-reply>

NETCONF messages layer is modeled with XML Schema 1.1 (XSD 1.1) in 
Appendix B.

While the <rpc-reply> in the original example is valid according to XML 
1.1 Schema in Appendix B, it does not seem to be consistent with 
requirements described in Appendix A. The text value of XML elements 
<bad-attribute> and <bad-element> should be a valid "xs:QName" that 
references a known attribute or element by its name ({namepace-name, 
local-part} tuple, not a string literal). Since the "message-id" 
attribute and "rpc" element do not belong to the same namespace in an 
<rpc> message, one of the text values in the original <rpc-reply> cannot 
be semantically correct.

It is also unclear which namespace unprefixed text values of XSD 1.1 
modeled data map to (and RFC 6241 says nothing about this), so my 
correction above is intentionally verbose in order to eliminate the 
default namespace. Note that the intention of the authors of XSD 1.1 
specification seems to be that such values are _always_ mapped to the 
null namespace, unlike in some other XML schema languages, where the 
default namespace would be used instead (if it exists), which would 
imply that only the value of <bad-element> in the original <rpc-reply> 
is problematic. The following could also be semantically correct:

      <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <rpc-error>
          <error-type>rpc</error-type>
          <error-tag>missing-attribute</error-tag>
          <error-severity>error</error-severity>
          <error-info>
            <bad-attribute>message-id</bad-attribute>
            <bad-element>nc:rpc</bad-element>
          </error-info>
        </rpc-error>
      </rpc-reply>

However, XSD 1.1 specification does not seem to explicitly confirm this 
anywhere.

Can someone please clarify what the intention of RFC 6241 was here? 
Specifically, why was XSD 1.1 "xs:QName" chosen as the data type for 
such XML elements in Appendix B, and what does "name" in Appendix A 
refer to?

Jernej