Good. But since we are getting a YANG doctor review, let’s wait for that before revving the draft.
Yoav > On 9 Apr 2019, at 10: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? > > >> El 5 abr 2019, a las 20:13, Yoav Nir <[email protected] >> <mailto:[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] >>> <mailto:[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> >> _______________________________________________ >> I2nsf mailing list >> [email protected] <mailto:[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] <mailto:[email protected]> > ------------------------------------------------------- > > > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
