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

Andy Bierman <> Fri, 02 April 2021 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA9DF3A1B1B for <>; Fri, 2 Apr 2021 08:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e2Z2dohRY7-b for <>; Fri, 2 Apr 2021 08:57:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C645E3A1B18 for <>; Fri, 2 Apr 2021 08:57:03 -0700 (PDT)
Received: by with SMTP id u4so6027903ljo.6 for <>; Fri, 02 Apr 2021 08:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WHZDRBMajNsItXn6WvqN4VymEag4oHy27Qxiu3r8160=; b=1+X7uUTQgEETFEQZkEYfZEzKyjaD03NWGKm9qlWPh6sdEEw6EWDMk6yE5mRdo9FTUz 9BcoAqdSTXRy6n/cT7kDWt+eZiYgji0fbqdl5AJLsErcfz0KjNeQrlEQo94ox6CEelfp pCCBdrGODcY6VschfvvpvkNEbDmv+cfq3MloZT73HsEuoEFE6ewW5fzmtrUfZqliZ88G KHJh+OG3KFjwj93rvhnGYdkm79LmqUnN2Jc7kZWEF33QyAm8fMNVegF4W5Tq95ygcWwX AwH4sb4XUkGUjcRKpBzZSeWEJG6QDYoi2nDy4fEyQXeGon5uKxul9ATshdkK4ZkXNQcY wx6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WHZDRBMajNsItXn6WvqN4VymEag4oHy27Qxiu3r8160=; b=OepLR4+luGrOlds09potZv0753z6JVcAUwNnd1mXPaIJbpKc1zNbHomauLFa8M/z/2 xd8afpiF2tUmO8ONzgEjJOacYuFH1NzgVpj8HBcy8giLHL00pFXttUfpR67mP5Xv9opn zLrZHu/lWmcWQcqof0yjicYD6d8UQMfhnlrL11z+h8M7L95pO/jY8Lk53MgN++SxiEeM YICDKWd7euxq1/YShtKylM1J1LdfKluuUQB5XjlS7ZpracUbaeq9O/rLn4RT2vJF6hx3 xPTVxz9zE9O1Zrp6TaBR1eixwLkdHjwRX7VlBMVEejXpwOZelmKed1iG4iSv3SIxJEOB hNOw==
X-Gm-Message-State: AOAM533TYMHjjlLCATibPbLII/ircozNTgcOMQXOQ35LkHNKY09Y5DcQ +KAoju/Zu6mt7ydjSyPo31HFkN9kH7iCayJAYZKedA==
X-Google-Smtp-Source: ABdhPJwKJNTGX52odMzBVT5SnzsdirW0Ca4edU5oQZiuz29lLfhmdaH3oJrCar0dxVtwmyS/Q/yspzV0iH73/uEDCNk=
X-Received: by 2002:a2e:9157:: with SMTP id q23mr9042112ljg.298.1617379020329; Fri, 02 Apr 2021 08:57:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 2 Apr 2021 08:56:49 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "Rob Wilton (rwilton)" <>, Juergen Schoenwaelder <>, RFC Errata System <>, Balazs Lengyel <>, "" <>, "" <>, Mahesh Jethanandani <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000f9693f05beff65cc"
Archived-At: <>
Subject: Re: [netconf] [Technical Errata Reported] RFC8341 (6493)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Apr 2021 15:57:09 -0000

On Fri, Apr 2, 2021 at 8:14 AM Kent Watsen <> 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
Since such a default would be extremely rare, this is not an interesting
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

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
(by introducing new types and deprecating the old ones).

> K.