Roman: The orchestration in the original charter was seen as "Yang models". I'm glad to work the IP-SEC orchestration + Yang models where the work goes.
Sue -----Original Message----- From: Roman Danyliw [mailto:r...@cert.org] Sent: Wednesday, March 23, 2022 9:20 AM To: Susan Hares; i2nsf@ietf.org Subject: RE: [I2nsf] Comments on re-chartering Hi! What's described below sounds like a great conversation to have. I don't sufficiently understand the existing gaps of "IP-SEC model[s] us[ing] BGP" to assess the volume or complexity of future work in that area. With an understanding of that scope, where this work should be done could also occur. Where there is clarity from my perspective is that the current I2NSF charter scope would not cover this kind of work. RFC9061 is a commendable body of work. However, the flexibility I exercised to ensure that it didn't get orphaned when I became the responsible AD of I2NSF does not expand the published WG scope. If there is a desire to do more Yang modeling work for IPSec that would take a re-charter or another WG. Regards, Roman > -----Original Message----- > From: Susan Hares <sha...@ndzh.com> > Sent: Wednesday, March 23, 2022 8:46 AM > To: Roman Danyliw <r...@cert.org>; i2nsf@ietf.org > Subject: RE: [I2nsf] Comments on re-chartering > > Roman: > > Good question! By mistake, I responded to just you. > > Here's the difficulty. IP-SEC knowledge is key to the restructure. And so is Yang > models. My personal experience in trying to get the IP-SEC model used by BGP > model, is that there are differences between the implementation of IPSEC > security boxes and routing box. For example, RFC8983 is a set of status > messages for IPsec. > > Do all of these message work equivalently for IPsec boxes and routing boxes? > I know how routing uses these features in securing links, but I am not a > security box expert. I am willing to be "cross-area" participant of I2NSF > to see that these definitions get thought through by both types of people. > > Either I2NSF in OPS/SEC, you need people for phrase 2 who are: > yang-experts, security-experts, deployment experts. If you move this to > OPS, will you get security experts? > > [Again - I am grateful to Paul and Tom Petch] > > Just giving you feedback from the trenches. > > Sue > > -----Original Message----- > From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Roman Danyliw > Sent: Tuesday, March 22, 2022 6:54 AM > To: Susan Hares; i2nsf@ietf.org > Subject: Re: [I2nsf] Comments on re-chartering > > Hi Sue! > > > -----Original Message----- > > From: Susan Hares <sha...@ndzh.com> > > Sent: Sunday, March 20, 2022 6:35 PM > > To: Roman Danyliw <r...@cert.org>; i2nsf@ietf.org > > Subject: RE: [I2nsf] Comments on re-chartering > > > > Roman: > > > > Security has created very few Yang modules. Therefore, you do not have > > experience with the lengthy cycle for this work. Ask Rob Wilton about > the > > versioning efforts or ask Alvaro regarding the routing yang models. Or > > look at the BGP model for complexity. > > ... > > > For example, I would like to get the I2NSF IP-SEC model adapted so > > that we > can > > use it in the BGP model. This takes chatting with the folks in I2NSF > > who > are > > experts. > > I've consulted with my peer-SEC ADs. If the community has interest to more > closely align this activity with the larger critical mass of work in Yang modules > in the IETF, we would be supportive of moving I2NSF to the OPS Area to finish > the remaining work or evolve it as appropriate. > > Regards, > Roman > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
