Re: [netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt

Wang Haiguang <> Mon, 24 June 2019 08:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 148A81200F4 for <>; Mon, 24 Jun 2019 01:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dz8NzAK5arOG for <>; Mon, 24 Jun 2019 01:31:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09753120048 for <>; Mon, 24 Jun 2019 01:31:58 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 9A36AF745EBE0A0DFCB0 for <>; Mon, 24 Jun 2019 09:31:56 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Jun 2019 09:31:55 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 24 Jun 2019 16:31:54 +0800
Received: from ([]) by ([]) with mapi id 15.01.1713.004; Mon, 24 Jun 2019 16:31:54 +0800
From: Wang Haiguang <>
To: "Xialiang (Frank, Network Standard & Patent Dept)" <>, Kent Watsen <>
CC: "" <>
Thread-Topic: [netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt
Thread-Index: AQHVKjSKZu7zG8Ux/E63K3NXr9Ju4qaqeCXg
Date: Mon, 24 Jun 2019 08:31:54 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-SG, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_12e28a734edc4df183eb8c64dd5f1bc3huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt
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: Mon, 24 Jun 2019 08:32:01 -0000

I am also have similar concern as Frank whether the values should be assigned by IANA or just use position order.

From a long term view, could the IANA assignment be a better choice?



From: netconf [] On Behalf Of Xialiang (Frank, Network Standard & Patent Dept)
Sent: Monday, June 24, 2019 10:28 AM
To: Kent Watsen <>
Subject: [netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt

Hi Kent and all,
Please see my comments inline:

发件人: netconf [] 代表 Kent Watsen
发送时间: 2019年6月20日 23:44
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

This update converts the algorithms from being identities to enumerations.

This is suppose to be the result from the thread started on April 25 entitled "The maintenance of the algorithm identifiers in draft-ietf-crypto-types" but, actually, I think it's from an earlier thread in which I believe Lada stated rationale for using enumerations instead of identities (I can't find that thread right now).   Seeing that the enum "values" are just in position-order, I'm unsure what issue this change resolves, but it seems nicer that a server doesn't have to *implement* the module, and also the values don't have to be prefixed...
[Frank]: FYI, the earlier thread discussing and proposing a good solution for currently using enumerations instead of identities is:   (Thanks Lada, Mahesh, Juergen, Martin, Andy, Acee, Paul Wouters and etc. for the productive discussion). The next issue to be addressed is whether the enum “values” can be in position-order, or should be the same as their respective IANA defined crypto algorithm numbers? For the latter case, which IANA should they be aligned: TLS, IPSec or SSH?

All said, I think that the maintainability issue remains.  IIRC, Tom Petch suggestion breaking the algorithms into smaller modules, that is, one module per what is now an "enumeration", and also I think that there was a recommendation for making these "iana-" modules...
[Frank]: Should we define the YANG modules for crypto types in yang IANA page?


This change is orthogonal to the update posted three days ago, which focused on how to support server-generated keys, etc.  No objections have been received so far, and thus I'm beginning to think it's okay and we can go into last call after the above discussion resolves.

Kent // contributor

On Jun 20, 2019, at 10:52 AM,<> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

       Title           : Common YANG Data Types for Cryptography
       Authors         : Kent Watsen
                         Wang Haiguang
  Filename        : draft-ietf-netconf-crypto-types-09.txt
  Pages           : 56
  Date            : 2019-06-20

  This document defines YANG identities, typedefs, the groupings useful
  for cryptographic applications.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

netconf mailing list<>