Re: [netconf] Create IANA-defined modules?

Kent Watsen <> Thu, 27 May 2021 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30A5F3A08EA for <>; Thu, 27 May 2021 12:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xaHviv_Qdyo2 for <>; Thu, 27 May 2021 12:15:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8B233A08E4 for <>; Thu, 27 May 2021 12:15:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1622142946; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=tG+kI0U0q6Ej3CQKZByrQGZVnHX3oHTeU6OB/47dj8Y=; b=SxIs0B5gdGpfv2C3j/fBX5JNqvGWBOw83bPiaryLmswjSlykA4hCV4Jlwp1Kam96 FJrRsg4YrIPnhhHdPhx+1RWLDE2w49yUFBW+Bix9vnpkhK9Vj1f0/zZdUmR9DvDF1s/ +59z2er+M9kEfVA/6h3t+XTY4+X95Baviygs5V3s=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Kent Watsen <>
In-Reply-To: <>
Date: Thu, 27 May 2021 19:15:46 +0000
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <>
To: Andy Bierman <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.05.27-
Archived-At: <>
Subject: Re: [netconf] Create IANA-defined modules?
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: Thu, 27 May 2021 19:15:49 -0000

Hi Andy,

> There are a couple comments I left out of the YD review…

No problem.

> 1) if-feature usage in identities
> IMO YANG conformance is still very spotty at best and conformance for identityref data nodes
> is especially broken.  I realize that if-feature is the standards-track solution to
> make a value optional-to-implement, but it is fragile, not future-proof, and adds unwarranted complexity.
> Since identityref conformance does not actually require any of the published identities
> to be used at all (only the base has to match), the entire concept of conformance for identities needs
> to be re-evaluated.
> Is it important to restrict the server to specific identities,
> or is it sufficient for the client to simply discover what identities are supported?
> It seems in many cases (e.g. iana-if-type) that the authors clearly do not intend
> whatsoever that every identity in the module be mandatory-to-implement.
> It seems like a discovery mechanism for identityref data nodes would be more
> useful than attempting to prune identities with if-feature-stmts.
> My preference is that all features and if-features related to identities be removed.

If we go the route of moving the identities to IANA-maintained modules, then this will likely happen automatically.   If we go the route of dropping the “common” modules altogether, then this becomes a non-issue.  In either case, the if-featured identities disappear.

> 2) perfect is the enemy of good
> The 5 year milestone is coming up on this work.
> Pencils down. Time to finish.


> Andy