Re: [netconf] Create IANA-defined modules?

Andy Bierman <> Thu, 27 May 2021 02:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AA153A05A7 for <>; Wed, 26 May 2021 19:29:35 -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 5GOAVhxW_PwX for <>; Wed, 26 May 2021 19:29:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C8663A02BE for <>; Wed, 26 May 2021 19:29:30 -0700 (PDT)
Received: by with SMTP id a5so4908508lfm.0 for <>; Wed, 26 May 2021 19:29:30 -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=kUidXTyR/04Quwylcgqh4T87CT/bM9BWvYJomaiaD6g=; b=JsU3ccQ5peW43IpAH3isWIU71TSM9he4v1CKWYlyJW7K8FUCOs0rvZvrVmxogKStqk DlQt1PEqx0IvGkTlQqh8/OaMw6yoUK1lCiZZQwxMcqlj/5Pw+6IOeh/YBoKQDYwgQXv3 rXuojoBnpIk+HrwNb7ppc1Xb2S5e6/KVSLdAO/dyTasC3UDm82N+1YFmWOZY/NWG7IT9 OtHFXoqx+7raTrpUrTQaIjP8TXWrZ+7gXjotRE5UYmG3KQt0IncYYZX9vyiLRoqaMbdD BaM5XtAIMejZ6VsdIcgSGGGJ+IbszyzlZc519/KleNdg3jfHjGE23jIEn2FaGKRsAm/I f4jg==
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=kUidXTyR/04Quwylcgqh4T87CT/bM9BWvYJomaiaD6g=; b=hnNWEy1IsbhDHLCpsR6ifranwVLlWpdwIOnNEi4g6RXBsDuhe2JxpEEn/RLjLmkYF2 WqFsJYGZbf9k0JPiIdXfO8qUEn6Ak3ODhwDnE0+FgoahoQXGEyEh+1TOnu8uYpqpDkY/ Dh8JQC6q1ZnDRSlPsmgMK3NGVI82qmnGsqtCp5HCgjAUNoPkcGxWUwY8g1bHz5uFVhn2 UjKeRKVwkCdY1GxtujWqnzeOYg9w8/sWsV68XQMe6t54PkPRhPme7ro00cABKM9ED0Bz L5XPW14/tS37MY7aCLkE+nvWqyMOO2QBFDRTDX1qYHDOgSMd/s+IiMZJOEihGbMdAUrp 08Yw==
X-Gm-Message-State: AOAM530R0L25I/lLM4+ZxHb9vSsdML8kyJuQywfSOhtlYqV8Kl/rCr33 LW0PbWIZQLhlHzYi3sldZc4IUOpwzi6z7By+Yns2hGhBJ11q4shY
X-Google-Smtp-Source: ABdhPJxfZFRjl0YI5uTCO/5EA80jv7wHbjTcgl6FPrl/lXqrzSFSF418APzaLyavZpKBwDNUwb0L/CC+B0KGgWA6HSs=
X-Received: by 2002:a05:6512:3453:: with SMTP id j19mr713996lfr.577.1622082567332; Wed, 26 May 2021 19:29:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Wed, 26 May 2021 19:29:16 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000038f9f805c3468732"
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 02:29:36 -0000


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

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

It seems in many cases (e.g. iana-if-type) that the authors clearly do not
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

2) perfect is the enemy of good

The 5 year milestone is coming up on this work.
Pencils down. Time to finish.


On Wed, May 26, 2021 at 12:06 PM Kent Watsen <> wrote:

> [CC-ing Gary, who contributed the “ietf-[tls/ssh]-common" modules
> originally]
> The “tls-client-server” draft just received the following GitHub “issue”:
> =====start=====
> This is rather a question than an issue, maybe.
> Given that IANA maintains the TLS parameters at
> would it not be better for that content to come from something like
> iana-tls[-parameters].yang rather than an IETF maintained YANG module?
> =====stop=====
> This is a good point.  Perhaps we should move all the identities for the
> algorithms defined in the “ietf-tls-common” module to an IANA-maintained
> “iana-tls-parameters” module.  Thoughts?
> By extension, the same statement applies to the “ssh-client-server” draft
> and the IANA maintained SSH parameters page:
> One potential issue with doing this is that the existing identities have
> “if-feature” statements that constrain them to specific TLS-versions and
> algorithm-families, and are sometimes marked as “deprecated".  By example:
>     identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
>        if-feature "tls-1_2";
>        if-feature "tls-ecc and tls-sha2";
>        base cipher-suite-base;
>        status "deprecated";
>        description
>            "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
>        reference
>           "RFC 5289: TLS Elliptic Curve Cipher Suites with
>                              SHA-256/384 and AES Galois Counter Mode
> (GCM)";
>     }
> But that information is NOT captured in the IANA-maintained page.   What
> to do?
> One option would be to drop all the feature statements.  All they do is
> limit the totality of algorithms presented to an administrator, when
> configuring which algorithms the client/server should support.  Worst case,
> all algorithms (of a given type) are presented, regardless if supported by
> the, e.g., TLS protocol version.  When configuring clients/servers using,
> e.g., text-based configuration files, such filters are never available.
> Does anyone know what Cisco/Juniper/etc. devices do in their command-line
> and/or web interfaces?
> Another option, which I like because it’s less work for me (unless someone
> can volunteer a GitHub pull request), is to remove the
> ietf-[tls/ssh]-common modules altogether.  They’re currently
> optional-to-configure and, when not configured, it’s an
> implementation-specific decision what, e.g., algorithms to list as being
> supported during the protocol handshake.  Personally, I’ve never used them
> (or implemented support for them), happily deferring to internal code and
> underlying libraries.  In lieu of us not defining these modules now,
> applications could augment-in their own configuration nodes and, of course,
> a future WG effort could add them.  Thoughts on this approach?
> K.
> _______________________________________________
> netconf mailing list