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

Martin Bjorklund <mbj@tail-f.com> Mon, 24 June 2019 10:52 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 6FE90120048 for <netconf@ietfa.amsl.com>; Mon, 24 Jun 2019 03:52:54 -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 Wp0EAhFc79kc for <netconf@ietfa.amsl.com>; Mon, 24 Jun 2019 03:52:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 283E6120098 for <netconf@ietf.org>; Mon, 24 Jun 2019 03:52:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 14EBE1AE0351; Mon, 24 Jun 2019 12:52:50 +0200 (CEST)
Date: Mon, 24 Jun 2019 12:52:53 +0200 (CEST)
Message-Id: <20190624.125253.527087934681043155.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016b758f31cd-97380f81-31bc-4eab-9bc0-af15545c47ab-000000@email.amazonses.com>
References: <156104236883.3035.10764109194950999587@ietfa.amsl.com> <0100016b758f31cd-97380f81-31bc-4eab-9bc0-af15545c47ab-000000@email.amazonses.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/p8oBYkx7Ps7J8ATsqFslX4ApvWg>
Subject: Re: [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 10:52:55 -0000

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