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

Hi Martin,
The new union definition of crypto algorithms aims to provide the flexibility of:
1. the uint16 can be used to represent current and future IANA defined crypto algorithms in number;
2. the enumeration can be used to represent current IANA defined crypto algorithms with better readability, and should be aligned with their values (which we are figuring out). 

Actually, it is proposed by Ladislav Lhotka, and discussed in I2NSF mailing list for some time. And it way mentioned that the similar definition has already been used in https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-01, and https://www.rfc-editor.org/rfc/rfc8294.txt.

B.R.
Frank

-----邮件原件-----
发件人: Martin Bjorklund [mailto:mbj@tail-f.com] 
发送时间: 2019年6月24日 20:12
收件人: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com>
抄送: kent+ietf@watsen.net; netconf@ietf.org
主题: Re: 答复: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

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-GLDAeN3Csg0
> gY4

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-ty
> > > pe
> > > 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