Hi Rob, Tom: Renaming the modules sounds reasonable. With regard to have a different prefix, it is also ok. Perhaps the easiest way is to solve this is the following: instead of using -sdn- we could include -i2nsf- so we would have: ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This would mean that this is in the context of i2nsf wg.
What do you think? > El 23 sept 2020, a las 12:45, tom petch <daedu...@btconnect.com > <mailto:daedu...@btconnect.com>> escribió: > > On 23/09/2020 11:24, Rob Wilton (rwilton) wrote: >> Hi Rafa, >> >> Thanks for replying with the extra background information. >> >> It seems like renaming the modules, as you propose for the -09 version, is >> the pragmatic path forward here. > > And the namespace and the YANG prefix IMHO. Having ike as a prrefix for a > module which is not the 'ike' module I see as a source of confusion. If this > is nsf specific, then I would suggest nsfike although nsfikeless then seems a > bit long. > > Tom Petch > >> Regards, >> Rob >> >> >> From: Rafa Marin-Lopez <r...@um.es <mailto:r...@um.es>> >> Sent: 23 September 2020 10:29 >> To: Rob Wilton (rwilton) <rwil...@cisco.com <mailto:rwil...@cisco.com>>; >> Christian Hopps <cho...@chopps.org <mailto:cho...@chopps.org>> >> Cc: Rafa Marin-Lopez <r...@um.es <mailto:r...@um.es>>; i2...@ietf.org >> <mailto:i2...@ietf.org>; Gabriel Lopez <gab...@um.es <mailto:gab...@um.es>>; >> draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org >> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org>; >> ipsec@ietf.org <mailto:ipsec@ietf.org>; last-c...@ietf.org >> <mailto:last-c...@ietf.org>; Martin Björklund <mbj+i...@4668.se >> <mailto:mbj+i...@4668.se>>; yang-doct...@ietf.org >> <mailto:yang-doct...@ietf.org> >> Subject: Re: [I2nsf] [yang-doctors] Yangdoctors last call review of >> draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >> >> Hi Rob, (Chris): >> >> Thank you very much for your answers. Please see our comments inline. >> >> >> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) >> <rwilton=40cisco....@dmarc.ietf.org >> <mailto:rwilton=40cisco....@dmarc.ietf.org><mailto:rwilton=40cisco....@dmarc.ietf.org >> <mailto:rwilton=40cisco....@dmarc.ietf.org>>> escribió: >> >> Hi Rafa, >> >> Thanks for getting back to me. >> >> Yes, changing the name of the module is an okay, if not ideal, resolution. >> But I appreciate that you also want to be done with this work. >> >> Correct, especially at this point of time. We have been discussing this I-D >> for a long time. There was a consensus in the WG. I2NSF WG chairs can >> comment about this. In our opinion, the changes that need to be applied are >> major changes from what it was approved in the WG. However, this is coming >> in the “last minute” and we feel this is not merely moving a few lines from >> here to there. We need to understand the impact of this. Therefore, it is >> not so trivial as it may seem. See below. >> >> >> >> But I would like to check: My understanding is that the changes that Chris >> is proposing are pretty small. I.e. move the SA structure under >> ipsec-common, and put it under a YANG feature. Are you sure that it is >> impractical to accommodate this change which would allow a single ipsec >> module to be shared and extended via YANG augmentations? >> >> >> In the context of our I-D, if we move SAD structure to ipsec-common, what we >> are meaning is that IPsec SA configuration data (setting values to the SAD >> structure) are common to the IKE case and the IKE-less cases, which are not. >> It is confusing. Moreover, the usage of feature means that, after all, this >> “common” is not “common” to both cases IKE case and IKE-less. Again, it >> seems confusing. In the IKE case, the SDN/I2NSF controller does not >> configure the SAD at all but the IKE implementation in the NSF. In our >> opinion, in order to properly add this IPsec SA operational state to the IKE >> case we should include operational data about the IPsec SAs (config false) >> to the ietf-ipsec-ike. Alternatively, we have certain operational data (ro) >> in the SAD structure in the IKE-less case. If only those are moved to the >> common part should be ok but we think it does not solve the problem. >> >> Therefore it is not only an implementation aspect. >> >> As you may observe, our discussion is taking into account there is an I2NSF >> Controller and we have two cases IKE case and IKE-less case, that have been >> discussed in the WG. The YANG model in the I-D has tried to reflect this >> discussion. It was never the intention to provide a general YANG model for >> IPsec. >> >> Best Regards. >> >> >> Thanks, >> Rob >> >> >> From: Rafa Marin-Lopez <r...@um.es <mailto:r...@um.es><mailto:r...@um.es >> <mailto:r...@um.es>>> >> Sent: 22 September 2020 14:05 >> To: Rob Wilton (rwilton) <rwil...@cisco.com >> <mailto:rwil...@cisco.com><mailto:rwil...@cisco.com >> <mailto:rwil...@cisco.com>>> >> Cc: Rafa Marin-Lopez <r...@um.es <mailto:r...@um.es><mailto:r...@um.es >> <mailto:r...@um.es>>>; Christian Hopps <cho...@chopps.org >> <mailto:cho...@chopps.org><mailto:cho...@chopps.org >> <mailto:cho...@chopps.org>>>; Gabriel Lopez <gab...@um.es >> <mailto:gab...@um.es><mailto:gab...@um.es <mailto:gab...@um.es>>>; >> draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org >> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org><mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org >> <mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection....@ietf.org>>; >> i2...@ietf.org <mailto:i2...@ietf.org><mailto:i2...@ietf.org >> <mailto:i2...@ietf.org>>; ipsec@ietf.org >> <mailto:ipsec@ietf.org><mailto:ipsec@ietf.org <mailto:ipsec@ietf.org>>; >> last-c...@ietf.org <mailto:last-c...@ietf.org><mailto:last-c...@ietf.org >> <mailto:last-c...@ietf.org>>; yang-doct...@ietf.org >> <mailto:yang-doct...@ietf.org><mailto:yang-doct...@ietf.org >> <mailto:yang-doct...@ietf.org>>; Martin Björklund <mbj+i...@4668.se >> <mailto:mbj+i...@4668.se><mailto:mbj+i...@4668.se <mailto:mbj+i...@4668.se>>> >> Subject: Re: [yang-doctors] Yangdoctors last call review of >> draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >> >> Dear Rob: >> >> Apologies for our delayed answer. We are now working in the revision to >> submit v09 by compiling all the comments. >> >> As you mentioned, we want to avoid any further delay. As we mentioned to >> Chris in the past (i2nsf mailing list), we do not have any problem to >> include some additional text (e.g. “-sdn-" in the module names). Therefore, >> Rob, we agree with your point of view about this. >> >> In summary, we are working in the next revision v09, and our idea to address >> Chris’ comments was to include -sdn- to the module names. >> >> We hope this is fine. >> >> Best regards. >> >> >> >> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) <rwil...@cisco.com >> <mailto:rwil...@cisco.com><mailto:rwil...@cisco.com >> <mailto:rwil...@cisco.com>>> escribió: >> >> Hi draft authors, Chris, >> >> Can we also please try and close on this issue raised by Chris. >> >> Chris, I don’t think that there is any great way to solve this issue using >> YANG features, but presumably the constraint could be enforced with a must >> statement, or groupings could be used to copy parts of the ipsec structure >> into an sdn specific ipsec tree structure. >> >> I understand that there isn't any great desire to delay these drafts by >> trying to generalize the ipsec YANG model contained within it. However, I >> think that means that the modules should have "-sdn-" in their names to >> indicate that they are intended specifically for the SDN use case, and >> should not be confused with the more generic ipsec YANG modules that have >> been proposed. >> >> Regards, >> Rob >> >> >> >> >> -----Original Message----- >> From: yang-doctors <yang-doctors-boun...@ietf.org >> <mailto:yang-doctors-boun...@ietf.org><mailto:yang-doctors-boun...@ietf.org >> <mailto:yang-doctors-boun...@ietf.org>>> On Behalf Of Christian >> Hopps >> Sent: 24 August 2020 18:08 >> To: Martin Björklund <mbj+i...@4668.se >> <mailto:mbj+i...@4668.se><mailto:mbj+i...@4668.se <mailto:mbj+i...@4668.se>>> >> Cc: i2...@ietf.org <mailto:i2...@ietf.org><mailto:i2...@ietf.org >> <mailto:i2...@ietf.org>>; draft-ietf-i2nsf-sdn-ipsec-flow- >> protection....@ietf.org >> <mailto:protection....@ietf.org><mailto:protection....@ietf.org >> <mailto:protection....@ietf.org>>; ipsec@ietf.org >> <mailto:ipsec@ietf.org><mailto:ipsec@ietf.org <mailto:ipsec@ietf.org>>; >> last-c...@ietf.org <mailto:last-c...@ietf.org><mailto:last-c...@ietf.org >> <mailto:last-c...@ietf.org>>; yang- >> doct...@ietf.org <mailto:doct...@ietf.org><mailto:doct...@ietf.org >> <mailto:doct...@ietf.org>> >> Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf- >> i2nsf-sdn-ipsec-flow-protection-08 >> >> [adding in ipsec@] >> >> Hi, >> >> This draft was discussed in ipsecme at the last IETF, and there was a >> desire to look closer at a couple changes that would make these models >> usable by ipsec generally rather than only for SDNs. Otherwise we will end >> up with 2 models that look very similar and duplicate almost all the >> functionality. This was going to be done during the next yang doctor >> review, but it looks like that happened in the meantime (ships in the >> night). >> >> At minimum the module names should include "-sdn-" if no other changes are >> made to indicate that they are only for sdn use; however, this is not the >> optimal solution. >> >> A better solution would be to move the containers currently under ikeless >> (for SA and Policy databases) under ipsec-common. >> >> The feedback I received from the authors was that the SDN controllers >> didn't care about the actual SAs and policies when using IKE so they >> didn't want to require someone implementing ike+common modules to have to >> support them. >> >> The YANG question I suppose is, is there an easy way to move these >> containers from ipsec-ikeless to ipsec-common, but still allow for them to >> be empty and/or unimplemented for the SDN IKE use case? If they were made >> features, is there a proper YANG way to indicate that if the ikeless >> module is present then those features must also be supported thus matching >> the functionality as defined by the current draft? >> >> Thanks, >> Chris. >> >> >> >> >> >> On Aug 24, 2020, at 10:37 AM, Martin Björklund via Datatracker >> <nore...@ietf.org <mailto:nore...@ietf.org><mailto:nore...@ietf.org >> <mailto:nore...@ietf.org>>> wrote: >> >> >> >> Reviewer: Martin Björklund >> Review result: Ready with Nits >> >> I did an early YANG Doctor's review of this draft. Most of my >> comments then have been addressed in this version. >> >> Comments: >> >> o As I wrote in my early review, the RFC editor enforces a common >> format of YANG modules, so it is better to adhere to this format >> before sending the draft to the RFC editor. Use >> >> pyang -f yang --yang-line-length 69 <FILE> >> >> to get a consistent look-and-feel for your module. >> >> (You will have to manually re-flow description statements after >> this.) >> >> >> o There are some leafs that are optional in the model, but w/o a >> default value and w/o an explanation of what happens if that leaf >> is not set. You should find those and either make them mandatory, >> add a default value, or explain what it means when it isn't set. >> As an example, >> /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret >> is optional. I suspect that this leaf needs to be mandatory. >> Another example is the leaf espencap. >> >> >> /martin >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doct...@ietf.org >> <mailto:yang-doct...@ietf.org><mailto:yang-doct...@ietf.org >> <mailto:yang-doct...@ietf.org>> >> https://www.ietf.org/mailman/listinfo/yang-doctors >> <https://www.ietf.org/mailman/listinfo/yang-doctors> >> >> >> ------------------------------------------------------- >> 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: r...@um.es<mailto:r...@um.es> >> ------------------------------------------------------- >> >> >> >> >> _______________________________________________ >> I2nsf mailing list >> i2...@ietf.org<mailto:i2...@ietf.org> >> 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: r...@um.es<mailto:r...@um.es> >> ------------------------------------------------------- >> >> >> >> >> >> ------------------------------------------------------- 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: r...@um.es <mailto:r...@um.es> -------------------------------------------------------
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
