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

[Martin Bjorklund <[e-mail]>]

Hi,


"Xialiang (Frank, Network Standard & Patent Dept)" <[e-mail]> 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:[e-mail]] 代表 Martin
> Bjorklund
> 发送时间: 2019年6月24日 18:53
> 收件人: [e-mail]
> 抄送: [e-mail]
> 主题: Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt
> 
> Hi,
> 
> Kent Watsen <[e-mail]> 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, [e-mail] 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf