> On Apr 9, 2019, at 09:49, Rafa Marin-Lopez <[email protected]> wrote: > > Hi Yoav: > > After thinking about these past days, I personally think the same. > > I would add a uint16 and a comment in the description. As we agreed in the > last IETF meeting, I do not think our I-D should solve this problem, since > this problem happens in general. > > As an example: > > typedef ike-integrity-algorithm-t { > type uint32; > description “The acceptable numbers are defined in IANA > Registry - Internet Key Exchange Version 2 (IKEv2) Parameters - IKEv2 > Transform Type 1 - Encryption Algorithm Transform IDs"; > } > > Is this reasonable?
This would be much better, yes. Paul > > >> El 5 abr 2019, a las 20:13, Yoav Nir <[email protected]> escribió: >> >> 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. >> >> 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]> wrote: >>>> Hi Linda, >>>> >>>> >>>>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[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] >>>>> https://www.ietf.org/mailman/listinfo/yang-doctors >>>> >>>> Mahesh Jethanandani >>>> [email protected] >>>> >>>> >>>> >>>> _______________________________________________ >>>> yang-doctors mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> _______________________________________________ >>> I2nsf mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/i2nsf >> >> _______________________________________________ >> I2nsf mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2nsf > > ------------------------------------------------------- > Rafa Marin-Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] > ------------------------------------------------------- > > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
