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

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Mon, 24 June 2019 11:33 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 961791200C4 for <netconf@ietfa.amsl.com>; Mon, 24 Jun 2019 04:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qaMfWu-p3Jyt for <netconf@ietfa.amsl.com>; Mon, 24 Jun 2019 04:33:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F0C12003F for <netconf@ietf.org>; Mon, 24 Jun 2019 04:33:15 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 722D0EEBD0F6226F9EE4 for <netconf@ietf.org>; Mon, 24 Jun 2019 12:33:13 +0100 (IST)
Received: from DGGEMM402-HUB.china.huawei.com ( by lhreml704-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Jun 2019 12:33:13 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([]) by DGGEMM402-HUB.china.huawei.com ([]) with mapi id 14.03.0439.000; Mon, 24 Jun 2019 19:31:07 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>, "kent+ietf@watsen.net" <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt
Thread-Index: AQHVJ3gWqvO+wlO2ckCVAWawaqasCaakKPCAgAX39YCAAI/DgA==
Date: Mon, 24 Jun 2019 11:31:07 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E7B05A1@dggemm511-mbx.china.huawei.com>
References: <156104236883.3035.10764109194950999587@ietfa.amsl.com> <0100016b758f31cd-97380f81-31bc-4eab-9bc0-af15545c47ab-000000@email.amazonses.com> <20190624.125253.527087934681043155.mbj@tail-f.com>
In-Reply-To: <20190624.125253.527087934681043155.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Ub7f-ZI6qTm-mvShLsH8bSxmrgo>
Subject: [netconf] 答复: I-D Action: draft-ietf-netconf-crypto-types-09.txt
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, 24 Jun 2019 11:33:19 -0000

Hi Martin,
Please see my last email about the previous discussion background for this change: https://mailarchive.ietf.org/arch/msg/netconf/pRkvMr0mTkYW-GLDAeN3Csg0gY4



发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Martin Bjorklund
发送时间: 2019年6月24日 18:53
收件人: kent+ietf@watsen.net
抄送: netconf@ietf.org
主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt


Kent Watsen <kent+ietf@watsen.net> wrote:
> 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"

I read that thread, but it doesn't discuss identities vs. enumerations at all.

> 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).

This is a pretty drastic change to this module, and it is based on a discussion that you think have taken place, but can't find?

I think we need to first decide what these types are suppposed to be.
The current design with a union seems to indicate that the type is either an alg registered by IANA or one of the enums (which then are not registered by IANA...??):

     typedef hash-algorithm-t {
       type union {
         type uint16;
         type enumeration {
           enum NONE {
             value 0;
               "Hash algorithm is NULL.";
           enum sha1 { ... }
         "The uint16 filed shall be set by individual protocol
          families according to the hash algorithm value assigned by
          IANA. ...";

There are several issues here: there is no reference to the IANA regsitry; enum NONE is questionable in configuration; the description seems to be copy-and-pasted ("protcol families").

I think that the only reason for using an enumeration instead of an identity is if we really want to lock down the possible values, which can be ok, e.g., if the values MUST be values in an IANA registry.

> 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...
> 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...

Yes, you probably want to make these modules reflect the IANA registries, compare with the iftype registry.

> 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.

I haven't checked this yet, but will do so now.


> Kent // contributor
> > On Jun 20, 2019, at 10:52 AM, internet-drafts@ietf.org 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
> > 
> > Abstract:
> >   This document defines YANG identities, typedefs, the groupings useful
> >   for cryptographic applications.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-09
> > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-type
> > s-09
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-09
> > 
> > 
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf

netconf mailing list