Re: [netconf] Order of elements in an input/output

Ladislav Lhotka <ladislav.lhotka@nic.cz> Tue, 30 March 2021 09:13 UTC

Return-Path: <ladislav.lhotka@nic.cz>
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 67E0B3A2C7A for <netconf@ietfa.amsl.com>; Tue, 30 Mar 2021 02:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 dBxe30B4HKyG for <netconf@ietfa.amsl.com>; Tue, 30 Mar 2021 02:13:38 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 B96C53A2C79 for <netconf@ietf.org>; Tue, 30 Mar 2021 02:13:37 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 512A1140579; Tue, 30 Mar 2021 11:13:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1617095614; bh=f4k7xhMQevfXEGWyYSrlbzqm7BoddCdka/Uy5w4NdgI=; h=From:To:Date; b=WaUF4Gbl9FZljqAbW6cWYW9Qe33ZWY/Zkg7hmetv/AsYI1YOpCqZVhYLlmwhgfWdf 45WGAsTc1xChxjbLR/HKNV1nqS8TdNCuu+hCIK1EZIG8toP7QNhfZA6inL9aEV9LmK fgCOrzclnCUojIDlhal6sgxEEjKVdUuSEa+udCDM=
From: Ladislav Lhotka <ladislav.lhotka@nic.cz>
To: Michal Vaško <mvasko@cesnet.cz>, netconf <netconf@ietf.org>
In-Reply-To: <39e5-6062e580-35-56ecb50@200194949>
References: <39e5-6062e580-35-56ecb50@200194949>
Mail-Followup-To: Michal Vaško <mvasko@cesnet.cz>, netconf <netconf@ietf.org>
Date: Tue, 30 Mar 2021 11:13:33 +0200
Message-ID: <87czvh0zsy.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4XQ3J1bIbWRZAqaLMKEjZKE1GCk>
Subject: Re: [netconf] Order of elements in an input/output
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: Tue, 30 Mar 2021 09:13:44 -0000

Michal Vaško <mvasko@cesnet.cz> writes:

> Hi,
>
> there seem to be 2 contradictory requirements for the order of
> input/output elements in a NETCONF message. It should be ordered [1]
> but augments can be applied in any order [2]. The only way to
> satisfy both requirements seem to be to enforce the order of base
> input/output elements but not for elements from augments. Is this
> interpretation correct?

One way to satisfy both requirements is to implement it as the interleave pattern in RELAX NG, the effects are described here:

http://books.xmlschemata.org/relaxng/relax-CHP-6-SECT-7.html

This means that parameters defined in place (inside the input/output statement) would have fixed order, and those defined in augments would have arbitrary order, and could also be intermingled with the in-place parameters.

This may possibly defeat the purpose of the fixed order though. On the other hand, I am not sure that this CLR is really needed - in JSON representation it cannot be enforced anyway.

Lada

>
> Regards,
> Michal
>
> [1] https://tools.ietf.org/html/rfc7950#section-7.14.4
> [2] https://tools.ietf.org/html/rfc7950#section-7.17.2
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67