Yoav Nir <[email protected]> writes: > At this point I’m wondering if it would not be a better strategy to > avoid all enumerations of algorithms, whether they are spelled out or > imported from draft-ietf-netconf-crypto-types, and instead use the > numbers from the IANA registry for IPsec. > > That does not help us deprecate old algorithms, but it solves the > other issue, which is what to do when a new algorithm is added to > IPsec. We don’t want to have to publish a new i2nsf document whenever > that happens, and if the algorithm identifier is just a number, new > values can be added by IANA.
IMO the best option is to combine an enumeration and numbers in a union type. We used this approach in this draft: https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-01 Lada > > Yoav > >> On 5 Apr 2019, at 20:42, Andy Bierman <[email protected]> wrote: >> >> Hi, >> >> I think conformance for identities is handled very poorly in YANG. >> There is an if-feature-stmt allowed inside an identity in YANG 1.1. >> This implies that any identity without if-feature is mandatory-to-implement. >> >> If the identities are in a separate module, the server can list it as an >> imported module, >> which tells the client the server does not implement any of the identities. >> >> There is no standard way for the server to inform the client which >> identities it supports >> for a given identityref data node. >> >> The common implementation strategy is to completely ignore YANG conformance >> for identities >> (as Mahesh explained). You just try setting the leaf and see if the server >> accepts it. >> >> Andy >> >> >> On Fri, Apr 5, 2019 at 10:33 AM Mahesh Jethanandani <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Linda, >> >> >>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Dear YANG Doctor: >>> >>> We need your help in reviewing the YANG model in >>> draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF WG is about to call >>> WGLC. >>> >>> In particular, we need your advice on the following issue: >>> >>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 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. >> >> All the algorithms in draft-ietf-netconf-crypto-types are defined as >> identities. If you do not find the algorithm you are looking for in the list >> of defined algorithms, you can go ahead and define your own in your own >> draft, using the same base identity from the ietf-crypto-types module. >> >>> >>> >>> Questions to the YANG Doctor: >>> 1. Is it better to list the IPsec specific algorithms in >>> draft-ietf-i2nsf-sdn-ipsec-flow-protection (which is a subset of >>> draft-ietf-netconf-crypto-types? Or to import all crypto algorithms many of >>> which are not relevant to IPsec? What is the common practice? >> >> Importing ietf-crypto-types does not mean you have to implement every >> algorithm listed in the module. You can import the module and chose to >> implement the algorithms you want to implement, including defining any new >> ones. >> >>> 2. If we do import from draft-ietf-netconf-crypto-types, does it mean >>> draft-ietf-i2nsf-sdn-ipsec-flow-protection cannot be published until >>> draft-ietf-netconf-crypto-types is published? >> >> Yes. The i2nsf draft will hit the state of MISSREF in the RFC Editor queue. >> But that should not prevent anyone from starting implementation of the >> module. As a side note, the NETCONF WG is planning on sending the >> crypto-types draft to IESG shortly. What you do not want is to duplicate the >> definition of the algorithms in your own draft. >> >> HTH. >> >>> >>> >>> Thank you very much, >>> >>> Linda & Yoav >>> >>> _______________________________________________ >>> yang-doctors mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> <https://www.ietf.org/mailman/listinfo/yang-doctors> >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> >> >> >> >> _______________________________________________ >> yang-doctors mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/yang-doctors >> <https://www.ietf.org/mailman/listinfo/yang-doctors> >> _______________________________________________ >> I2nsf mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2nsf >> <https://www.ietf.org/mailman/listinfo/i2nsf> > _______________________________________________ > yang-doctors mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
