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

If you "only" want to represent an IANA-maintained registry, you can
create an IANA-maintained YANG module with the enums from that
registry.  That YANG module will by definition always be up to date.
No need to handle integers for this.

Or, if you want extensibility, you can use the approach that we used
in the "iana-if-type" YANG module with identities.


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

I believe this use case is a bit different, or rather I don't think
there's a one-size-fits-all solution to this problem.

So, to start with, for each of the types in the crypto module, could
you specify the link to the corresponding IANA registry?


Also, the thread on the I2NSF ML started with this question:

  [our draft[ imports from draft-ietf-netconf-crypto-types, which
  appears to be a generic list of algorithms.

  The problem is that the list in draft-ietf-netconf-crypto-types
  could contain algorithms that are not suitable for IPsec (such as
  secp192r1 for key agreement), and right now it seems to lack some
  older algorithms that have fallen out of fashion (3DES) but is still
  needed in IPsec.

The solution you propose doesn't solve this problem.

(Perhaps it is not a coincident that IANA lists 15+ different hash
function registries, for various applications)



/martin




> 
> B.R.
> Frank
> 
> 
> -----邮件原件-----
> 发件人: Martin Bjorklund [mailto:[e-mail]] 
> 发送时间: 2019年6月24日 20:12
> 收件人: Xialiang (Frank, Network Standard & Patent Dept)
> <[e-mail]>
> 抄送: [e-mail]; [e-mail]
> 主题: Re: 答复: [netconf] I-D Action:
> draft-ietf-netconf-crypto-types-09.txt
> 
> 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-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:[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-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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > 
> > 
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf