Re: [netconf] [Technical Errata Reported] RFC8341 (6493)

Martin Björklund <mbj+ietf@4668.se> Mon, 05 April 2021 11:16 UTC

Return-Path: <mbj+ietf@4668.se>
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 7FD1B3A139A for <netconf@ietfa.amsl.com>; Mon, 5 Apr 2021 04:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=IonU2Cp/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LTk26jDT
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 vB6TzU6q4qBI for <netconf@ietfa.amsl.com>; Mon, 5 Apr 2021 04:16:14 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602993A1398 for <netconf@ietf.org>; Mon, 5 Apr 2021 04:16:14 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2D03617A8; Mon, 5 Apr 2021 07:16:09 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 05 Apr 2021 07:16:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= j4lYU2JT/J+Az8mRB+2pBmCXK2Y70rHajz0aydCEUe0=; b=IonU2Cp/imM+XLd9 w2vHEcXyzHsJYeOPRBnF2kb5CzjrJqf6p5P8FxAtLc7jbzYsyjGtOTcCTTpLUITk Zl8/s3oj9N5muZiNcYaC1ChxLusRbrAWTzoRf6a8Bw5vZ8tzOayYhvgYQyTmUCMe eb3ZUDezxRitoYXyDQ0jYUpAdtjlZACt+TvetQ0WXoI4DkKooyFL0mrfX4Qz0yxA 8S4alvvKPJE8vpbIw/PJokWJG60Mx2DkiFpGt0GX57O3TlUUvrgkxY/1a7nRzDb4 ZZOPqVsayydJV9jqB64aTCwbbNqjj1zLRCXNSUp/ZgXNtTyiSdEPmYqT/XZ3gQqv 91mItw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=j4lYU2JT/J+Az8mRB+2pBmCXK2Y70rHajz0aydCEU e0=; b=LTk26jDTudpyRuu0vMxaXNj7IQAF3aZ7jHvXOMVzkeWtxbp8aN+0g0fCV DiAHy8naA3xXGoVgdKUhc+qYXZ3FeAw6BPH1CPXRNYGjJdlljhkEQBVhqW9/f9jd MxI/0Xz2h7b3/gxGunhuDOpkF19Yt9qHYqVD0ugc0p0OL7Sx8rDZxXm6uPYKuHWm PptW5Q6clw+zNM38cn2KW3sifZx+9686mU7jjX0C51Q7KHg50hwMYcgy/t7SH5Uz wRRuVp+gap+7g+1NeOX8ug7gXLeBaVN4Tmp7YxCxdXCzIIat9pKlD4Z3fRTmtOlP ancKUbaiqpaIXvb61ZnZylYGydOIw==
X-ME-Sender: <xms:dvFqYOu9TUrojGnWP8nQDlk0UVkgf060-AJN7iHK8YTrtEVda4L0DQ> <xme:dvFqYDcbVaLkD7fLVkTKFtSQruRl6vWu5uSRpRWP7fznv6J4kbOMasxV37EAJopcJ Y48flO0YAspGwLgTis>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejvddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnheptedvfffhgeejffeljeeuve ekudevfeduudduteetveelieekgfdtieekudeiudevnecuffhomhgrihhnpehgihhthhhu sgdrtghomhenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhs vg
X-ME-Proxy: <xmx:dvFqYJxYxFRcwmA2beDqZ8vKgDsKoCebwzWOtwy5limY2LKGNJSq8Q> <xmx:dvFqYJNO6btwnayWbdQ0NXDLKRNBSwImwoto0ckGR9_7e8C8KnDs8g> <xmx:dvFqYO9KtsSOBEYGu1r74aTQIZB5V8RD_WsWebCaEectDWGqiqvrMQ> <xmx:ePFqYFZx0ypkFoteO5x6S1otE1iMFZhO46uOtqp9JiiGZc1wvF64Zw>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A776240057; Mon, 5 Apr 2021 07:16:06 -0400 (EDT)
Date: Mon, 05 Apr 2021 13:16:04 +0200 (CEST)
Message-Id: <20210405.131604.1874714527132991309.id@4668.se>
To: andy@yumaworks.com
Cc: kent+ietf@watsen.net, mbj@tail-f.com, netconf@ietf.org, warren@kumari.net, rfc-editor@rfc-editor.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <CABCOCHQxcq1LLrsEPYWPd3sOS1KK9pLj29uGxQcgFOZjXS3HuQ@mail.gmail.com>
References: <MN2PR11MB4366E67DEA2E17B448DA339CB5629@MN2PR11MB4366.namprd11.prod.outlook.com> <01000178932683b3-f9a114b8-b525-479e-b7f2-ff8300b32d14-000000@email.amazonses.com> <CABCOCHQxcq1LLrsEPYWPd3sOS1KK9pLj29uGxQcgFOZjXS3HuQ@mail.gmail.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4y8LKFE42HuT9vyrkRr2qWvuMFU>
Subject: Re: [netconf] [Technical Errata Reported] RFC8341 (6493)
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: Mon, 05 Apr 2021 11:16:20 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Apr 2, 2021 at 8:14 AM Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> >
> > I agree with Juergen that section 9.13.2 of RFC 7950 applies and hence my
> > opinion is that this errata, against RFC 8341, should be rejected.
> >
> >
> > +1 (as contributor)
> >
> >
> > However, I also think that RFC 7950 isn't as clear as it should be.  Given
> > that there is an explicit ABNF construct for instance-identifier, I really
> > think that this ABNF should explicitly require prefixes for
> > node-identifiers, avoiding any potential ambiguity in what is allowed.
> >
> >
> > Should a YANG-next issue be filed?
> >
> 
> 
> We could think a bit about the real problems with instance-identifier
> instead of academic discussions.
> 
> The ABNF only describes the syntax of the default-stmt representation of an
> instance-identifier.
> Since such a default would be extremely rare, this is not an interesting
> problem.
> The RFC is clear that prefixes are required.
> 
> The protocol message (or artifact) representation of an instance-identifier
> is a much more relevant use-case.
> XML has its own rules for binding namespaces to QNames in the context of an
> XML instance document.
> These rules are clear, so no problem to be solved here.
> 
> The real problem (for yang-next?) is that the instance-identifier and
> identityref data types
> do not have any context-free representation possible, let alone a canonical
> representation.

There is an YANG-next issue for this problem
(https://github.com/netmod-wg/yang-next/issues/56)



/martin


> 
> The solution already exists in RFC 7951 (6.8 and 6.11).
> These encoding rules for identityref and instance-identifier should be used
> for all
> representations, and the default-stmt, The XML and YANG encodings should be
> replaced
> (by introducing new types and deprecating the old ones).
> 
> 
> >
> > K.
> >
> >
> Andy