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

Martin Bjorklund <mbj@tail-f.com> Mon, 24 June 2019 12:11 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED2E12027E for <netconf@ietfa.amsl.com>; Mon, 24 Jun 2019 05:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQyl5GSOyQma for <netconf@ietfa.amsl.com>; Mon, 24 Jun 2019 05:11:32 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C149112015F for <netconf@ietf.org>; Mon, 24 Jun 2019 05:11:31 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 75B771AE0351; Mon, 24 Jun 2019 14:11:29 +0200 (CEST)
Date: Mon, 24 Jun 2019 14:11:33 +0200 (CEST)
Message-Id: <20190624.141133.2212333006903943160.mbj@tail-f.com>
To: frank.xialiang@huawei.com
Cc: kent+ietf@watsen.net, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E7B05A1@dggemm511-mbx.china.huawei.com>
References: <0100016b758f31cd-97380f81-31bc-4eab-9bc0-af15545c47ab-000000@email.amazonses.com> <20190624.125253.527087934681043155.mbj@tail-f.com> <C02846B1344F344EB4FAA6FA7AF481F13E7B05A1@dggemm511-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KBfkjMTWwcuVI-38QNDKEC0JMnw>
Subject: Re: [netconf] =?utf-8?b?562U5aSNOiAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1u?= =?utf-8?q?etconf-crypto-types-09=2Etxt?=
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 12:11:34 -0000

Hi,


"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>; wrote:
> Hi Martin,
> Please see my last email about the previous discussion background for
> this change:
> https://mailarchive.ietf.org/arch/msg/netconf/pRkvMr0mTkYW-GLDAeN3Csg0gY4

Ok I have read this thread.  It talks about a number of problems.

Can you explain which problem is solved by this change?


/martin


> 
> Thanks!
> 
> B.R.
> Frank
> 
> -----邮件原件-----
> 发件人: 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
> 
> Hi,
> 
> 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;
>              description
>                "Hash algorithm is NULL.";
>            }
>            enum sha1 { ... }
>            ...
>          }
>        }
>        description
>          "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.
> 
> 
> /martin
> 
> 
> > 
> > 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
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf