Re: [I2nsf] Comments on re-chartering
Tom: Thank you for your interesting perspective. I think that your observation here that states: "YANG, like Security, is an arcane subject but knowledge of it is now widespread, inside and outside the IETF. Where I think that I see the YANG work go wrong, in several WG, is at the start, getting the structure, the scope, wrong and that is hard to change later so may not get changed (my comments on the lack of a common I2NSF I-D, module, definitions and so on, are in that vein). Security, by contrast, can often be fixed late in the day with a judicious tweak to Security Considerations or by the addition of nacm:default deny-all in the YANG." I agree that Yang and Security are arcane subjects. Some people say BGP is arcane as well. Some say the IP, TCP, internet stuff is arcane. Having sat in this WG since the beginning, disagree that it has been easy to judge the structure, scope and set-up initially. Especially, when these models started (pre-NDMA, RFC8342).I also think that the WG had more guidance at the front of the process. Including Adrian (one WG chair) who has a fairly deep knowledge on this topic. In my humble opinion, I think this working group (I2NSF) is trying to change security's paradigm. I agree with you that it is at the heart of cross-area struggles. It is at the nexus of security, yang, TCP/IP, and others. Where would you put these models? That's the real question. Today's attempts (post-NDMA, caused by I2RS struggles), will be wiser than the original models. IMHO - The chaos in the Yang world led to many initially questionable choices. Paul, his team and you have done a fabulous job at the working through refactoring. I support the re-chartering because I would like to allow the group to try additional security Yang models. If there are other groups chomping at the bit to create security Yang models, then perhaps the work can move. I still believe in the Yang data-driven dream. Sue -Original Message- From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of t petch Sent: Thursday, March 24, 2022 7:22 AM To: Roman Danyliw; Susan Hares; i2nsf@ietf.org Subject: Re: [I2nsf] Comments on re-chartering On 22/03/2022 10:54, Roman Danyliw wrote: > Hi Sue! > >> -Original Message- >> From: Susan Hares >> Sent: Sunday, March 20, 2022 6:35 PM >> To: Roman Danyliw ; 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. YANG, like Security, is an arcane subject but knowledge of it is now widespread, inside and outside the IETF. Where I think that I see the YANG work go wrong, in several WG, is at the start, getting the structure, the scope, wrong and that is hard to change later so may not get changed (my comments on the lack of a common I2NSF I-D, module, definitions and so on, are in that vein). Security, by contrast, can often be fixed late in the day with a judicious tweak to Security Considerations or by the addition of nacm:default deny-all in the YANG. With the work of I2NSF so far, I see few YANG problems of any account, apart from the one I mentioned. By contrast, I have seen many issues arising from a lack of familiarity with core IETF protocols - IP, ICMP, TCP. DCCP, HTTP, POP3 and so on - and the most recent set of I-D may repeat that pattern. My knowledge of these protocols is basic but is enough to see over and over again that the I-D needs changing or that a change made is inappropriate. Given the wide scope of the current I2NSF I-D, I find it hard to suggest a better home for them; rather, they would have benefitted from ...art reviews at an earlier stage. If the focus changes, for example to provide a focus on BGP, then a move to an Area or WG with skills in that focus would seem prudent. The Security Area, as I have commented before, is lagging in producing YANG modules for others to use and other WG have stepped in, with or without success; the Routing Area, by contrast, has produced a wealth of material but I do not see YANG skills, or lack thereof, as a factor in the current work of the I2NSF WG; rather a lac
Re: [I2nsf] Comments on re-chartering
On 22/03/2022 10:54, Roman Danyliw wrote: Hi Sue! -Original Message- From: Susan Hares Sent: Sunday, March 20, 2022 6:35 PM To: Roman Danyliw ; 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. YANG, like Security, is an arcane subject but knowledge of it is now widespread, inside and outside the IETF. Where I think that I see the YANG work go wrong, in several WG, is at the start, getting the structure, the scope, wrong and that is hard to change later so may not get changed (my comments on the lack of a common I2NSF I-D, module, definitions and so on, are in that vein). Security, by contrast, can often be fixed late in the day with a judicious tweak to Security Considerations or by the addition of nacm:default deny-all in the YANG. With the work of I2NSF so far, I see few YANG problems of any account, apart from the one I mentioned. By contrast, I have seen many issues arising from a lack of familiarity with core IETF protocols - IP, ICMP, TCP. DCCP, HTTP, POP3 and so on - and the most recent set of I-D may repeat that pattern. My knowledge of these protocols is basic but is enough to see over and over again that the I-D needs changing or that a change made is inappropriate. Given the wide scope of the current I2NSF I-D, I find it hard to suggest a better home for them; rather, they would have benefitted from ...art reviews at an earlier stage. If the focus changes, for example to provide a focus on BGP, then a move to an Area or WG with skills in that focus would seem prudent. The Security Area, as I have commented before, is lagging in producing YANG modules for others to use and other WG have stepped in, with or without success; the Routing Area, by contrast, has produced a wealth of material but I do not see YANG skills, or lack thereof, as a factor in the current work of the I2NSF WG; rather a lack of familiarity with the other work of the IETF Tom Petch. 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
Re: [I2nsf] Comments on re-chartering
Paul: I'm a bit lost about the last sentences. If you could explain "re-reading new IANA registry values creates by new RFCs. Thank you for your feedback, Sue -Original Message- From: Paul Wouters [mailto:p...@nohats.ca] Sent: Wednesday, March 23, 2022 5:34 PM To: Susan Hares Cc: Roman Danyliw; i2nsf@ietf.org Subject: Re: [I2nsf] Comments on re-chartering On Mar 23, 2022, at 13:47, Susan Hares wrote: > > 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. I am willing to help with ipsec related work for i2nsf, wherever the WG lives. > For example, RFC8983 is a set of > status messages for IPsec. > > Do all of these message work equivalently for IPsec boxes and routing boxes? Those messages are specific to Remote Access VPN setups and would not be used by BGP routers using IPsec in static IPs. > I am willing to be "cross-area" participant of I2NSF to see that > these definitions get thought through by both types of people. Same. I do think the bulk of the work of the WG is not security related, since it often involves (re-)reading new IANA registry values creates by new RFCs. Paul ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] Comments on re-chartering
On Mar 23, 2022, at 13:47, Susan Hares wrote: > > 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. I am willing to help with ipsec related work for i2nsf, wherever the WG lives. > For example, RFC8983 is a set of > status messages for IPsec. > > Do all of these message work equivalently for IPsec boxes and routing boxes? Those messages are specific to Remote Access VPN setups and would not be used by BGP routers using IPsec in static IPs. > I am willing to be "cross-area" participant of I2NSF > to see that these definitions get thought through by both types of people. Same. I do think the bulk of the work of the WG is not security related, since it often involves (re-)reading new IANA registry values creates by new RFCs. Paul ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] Comments on re-chartering
Roman: I was imprecise. You interpretation of the original charter is correct. The orchestration was with specific Yang models. Thanks for responding! Sue -Original Message- From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Roman Danyliw Sent: Wednesday, March 23, 2022 9:51 AM To: Susan Hares; i2nsf@ietf.org Subject: Re: [I2nsf] Comments on re-chartering Hi Sue! > -Original Message- > From: Susan Hares > Sent: Wednesday, March 23, 2022 9:27 AM > To: Roman Danyliw ; i2nsf@ietf.org > Subject: RE: [I2nsf] Comments on re-chartering > > Roman: > > The orchestration in the original charter was seen as "Yang models". Publishing particular yang modules is definitely in scope. Respectfully, I don't read the charter to have a scope to support orchestration generically with any yang module. > I'm > glad to work the IP-SEC orchestration + Yang models where the work goes. Wonderful. Regards, Roman > 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 > > Sent: Wednesday, March 23, 2022 8:46 AM > > To: Roman Danyliw ; 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 > > > Sent: Sunday, March 20, 2022 6:35 PM > > > To: Roman Danyliw ; 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 ___ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
Re: [I2nsf] Comments on re-chartering
Hi Sue! > -Original Message- > From: Susan Hares > Sent: Wednesday, March 23, 2022 9:27 AM > To: Roman Danyliw ; i2nsf@ietf.org > Subject: RE: [I2nsf] Comments on re-chartering > > Roman: > > The orchestration in the original charter was seen as "Yang models". Publishing particular yang modules is definitely in scope. Respectfully, I don't read the charter to have a scope to support orchestration generically with any yang module. > I'm > glad to work the IP-SEC orchestration + Yang models where the work goes. Wonderful. Regards, Roman > 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 > > Sent: Wednesday, March 23, 2022 8:46 AM > > To: Roman Danyliw ; 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 > > > Sent: Sunday, March 20, 2022 6:35 PM > > > To: Roman Danyliw ; 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
Re: [I2nsf] Comments on re-chartering
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 > Sent: Wednesday, March 23, 2022 8:46 AM > To: Roman Danyliw ; 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 > > Sent: Sunday, March 20, 2022 6:35 PM > > To: Roman Danyliw ; 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
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 > Sent: Wednesday, March 23, 2022 8:46 AM > To: Roman Danyliw ; 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 > > Sent: Sunday, March 20, 2022 6:35 PM > > To: Roman Danyliw ; 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
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 > Sent: Sunday, March 20, 2022 6:35 PM > To: Roman Danyliw ; 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
Re: [I2nsf] Comments on re-chartering
Hi Sue! > -Original Message- > From: Susan Hares > Sent: Sunday, March 20, 2022 6:35 PM > To: Roman Danyliw ; 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
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. Data driven Yang models are extremely powerful, but these models take 2-3 passes to the internal structure right. During the 2nd and 3rd passes, the WG participation is low because Yang refactoring is not an easy or common skill. Yang refactoring + security + I2NSF models is a very rare skill. You are looking at working group participation as we "hold" for getting the last 5 models correct. We are in the 3rd stage of work for these models. It takes time to get the models right, but it is something that takes 2-3 people with a rare set of experience time. Do I believe that IETF Yang models are beneficial? Yes, because they influence open source + the future of network management work. Even Open-Config (ask Rob about that story), is taking fixes from the bgp model refactoring. My recommendation is that you consider the life-cycle of Yang models in reviewing a WG. If you are going to hold on 5 models in phase-3, put the WG in hiatus while the experts work. Or decide to start-up work that I2NSF WG participants can help with. NETMOD exist at the center of YANG creation, but even in these WGS there are few experts implementing the code. Most people review the high-level concepts, and it takes time to get the high level concepts sorted out. 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 hope this longish message is helpful. Sue PS - The BGP model is at draft-ietf-idr-bgp-model-13.txt. -Original Message- From: Roman Danyliw [mailto:r...@cert.org] Sent: Sunday, March 20, 2022 5:03 PM To: Susan Hares; i2nsf@ietf.org Subject: RE: [I2nsf] Comments on re-chartering Hi Sue! > -Original Message- > From: I2nsf On Behalf Of Susan Hares > Sent: Sunday, March 20, 2022 3:12 PM > To: Roman Danyliw ; i2nsf@ietf.org > Subject: Re: [I2nsf] Comments on re-chartering > > Roman: > > May I ask a questions before answering your questions. I don't have comprehensive data on any of these. The datatracker likely has some of this information but it would take effort to extract. > 1) How many security Yang models have been published? My sense is that that the number of Yang models from the SEC area is low in in comparison to other areas. Other areas do publish Yang modules on Sec related topics. > 2) How long does it take Yang models approved in the security area? I'm only tracking two data points -- I2NSF and RATS. https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ was adopted by the RATS WG in January 2020 and reviewed by the IESG at the last 03/10/2022 telechat. If you count from the first individual draft -00, then the time starts at Jul 2018 (which was even before the first RATS BOF at IETF 103). > 3) How many IETF yang models have been deployed? I can't say. For Yang module and most IETF work, there isn't a good sense of that answer in the aggregate. My experience is that specific WGs have a better sense of implementations and adoption of their technologies. Perhaps the I2NSF Yang module authors can give us a sense of adoption. > 4) Does the small deployment for IETF yang models change the value of the > model? At the risk of getting philosophical, such a hypothetical question depends on your definition of value, who are the stakeholders, and desired payoff horizon this technology. > The SEC-ADs sent this WG off to create Yang models. Did you consider this > in your review? I definitely considered the existing I2NSF charter and the planned milestones before my review. This WG was not so much sent off to create Yang models as, like every WG, approved with a specific scope, in this case making Yang models for a narrow scope. > May I politely and respectfully suggest there are things about the standardizing > Yang models that you have not asked about. > > The first stage of a yang model is joyous. You decide what goes in. The > second of getting a prototype yang model implementation is hard work. The > third stage of getting the model approved in the IETF environment is > frustrating and painful.During the second and third stage, most WGs have > trouble keeping up the energy - since it is all about the small details of > Yang. Help me understand how to read this progression as it relates to the I2NSF documents. What didn't I ask? > Tom Petch has been very helpful, but it is a long process to refactored > structures in Yang. Paul has done a tremendous job in both doing prototype > implementations, and working through the leng
Re: [I2nsf] Comments on re-chartering
Hi Roman, Putting aside the most "philosophical" questions (though I strongly share Susan's view about the slow start of many of the YANG models), let me just share a reflection on the (I'd daresay evident) need for YANG modules related to security protocols. If the current proposed new charter for I2NSF is not appropriate to address need, would this imply that we should need a more radical re-chartering? Why would a different, new WG be required to deal with this goal? Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/ e-mail: diego.r.lo...@telefonica.com Mobile: +34 682 051 091 -- On 20/03/2022, 22:03, "I2nsf on behalf of Roman Danyliw" wrote: Hi Sue! > -Original Message- > From: I2nsf On Behalf Of Susan Hares > Sent: Sunday, March 20, 2022 3:12 PM > To: Roman Danyliw ; i2nsf@ietf.org > Subject: Re: [I2nsf] Comments on re-chartering > > Roman: > > May I ask a questions before answering your questions. I don't have comprehensive data on any of these. The datatracker likely has some of this information but it would take effort to extract. > 1) How many security Yang models have been published? My sense is that that the number of Yang models from the SEC area is low in in comparison to other areas. Other areas do publish Yang modules on Sec related topics. > 2) How long does it take Yang models approved in the security area? I'm only tracking two data points -- I2NSF and RATS. https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ was adopted by the RATS WG in January 2020 and reviewed by the IESG at the last 03/10/2022 telechat. If you count from the first individual draft -00, then the time starts at Jul 2018 (which was even before the first RATS BOF at IETF 103). > 3) How many IETF yang models have been deployed? I can't say. For Yang module and most IETF work, there isn't a good sense of that answer in the aggregate. My experience is that specific WGs have a better sense of implementations and adoption of their technologies. Perhaps the I2NSF Yang module authors can give us a sense of adoption. > 4) Does the small deployment for IETF yang models change the value of the > model? At the risk of getting philosophical, such a hypothetical question depends on your definition of value, who are the stakeholders, and desired payoff horizon this technology. > The SEC-ADs sent this WG off to create Yang models. Did you consider this > in your review? I definitely considered the existing I2NSF charter and the planned milestones before my review. This WG was not so much sent off to create Yang models as, like every WG, approved with a specific scope, in this case making Yang models for a narrow scope. > May I politely and respectfully suggest there are things about the standardizing > Yang models that you have not asked about. > > The first stage of a yang model is joyous. You decide what goes in. The > second of getting a prototype yang model implementation is hard work. The > third stage of getting the model approved in the IETF environment is > frustrating and painful.During the second and third stage, most WGs have > trouble keeping up the energy - since it is all about the small details of > Yang. Help me understand how to read this progression as it relates to the I2NSF documents. What didn't I ask? > Tom Petch has been very helpful, but it is a long process to refactored > structures in Yang. Paul has done a tremendous job in both doing prototype > implementations, and working through the lengthy issues with the Yang > models. While completing those 5 models, Paul has run into many of the > structural issues/debates inside Yang. I couldn't agree with you more. Paul and Tom have a done a tremendous and admirable job on the core I2NSF data models. > Having struggle to incorporate yang models from IP-SEC into the BGP model > (with my excellent co-authors), may I suggest that even the IP-SEC models > are just at the beginning from I2NSF.Maybe there are other IP-SEC Yang > models outside of I2NSF. The community would know better than me on what future work is needed to better manage security protocols, IPSec, or otherwise with Yang modules. I don't see the I2NSF WG being the place to do that Yang work for security protocols in the general case. Roman > Sue > > -Original Message- > From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Roman Danyliw > Sent: Sunday, March 20, 2022 2:33 PM >
Re: [I2nsf] Comments on re-chartering
Hi Sue! > -Original Message- > From: I2nsf On Behalf Of Susan Hares > Sent: Sunday, March 20, 2022 3:12 PM > To: Roman Danyliw ; i2nsf@ietf.org > Subject: Re: [I2nsf] Comments on re-chartering > > Roman: > > May I ask a questions before answering your questions. I don't have comprehensive data on any of these. The datatracker likely has some of this information but it would take effort to extract. > 1) How many security Yang models have been published? My sense is that that the number of Yang models from the SEC area is low in in comparison to other areas. Other areas do publish Yang modules on Sec related topics. > 2) How long does it take Yang models approved in the security area? I'm only tracking two data points -- I2NSF and RATS. https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/ was adopted by the RATS WG in January 2020 and reviewed by the IESG at the last 03/10/2022 telechat. If you count from the first individual draft -00, then the time starts at Jul 2018 (which was even before the first RATS BOF at IETF 103). > 3) How many IETF yang models have been deployed? I can't say. For Yang module and most IETF work, there isn't a good sense of that answer in the aggregate. My experience is that specific WGs have a better sense of implementations and adoption of their technologies. Perhaps the I2NSF Yang module authors can give us a sense of adoption. > 4) Does the small deployment for IETF yang models change the value of the > model? At the risk of getting philosophical, such a hypothetical question depends on your definition of value, who are the stakeholders, and desired payoff horizon this technology. > The SEC-ADs sent this WG off to create Yang models. Did you consider this > in your review? I definitely considered the existing I2NSF charter and the planned milestones before my review. This WG was not so much sent off to create Yang models as, like every WG, approved with a specific scope, in this case making Yang models for a narrow scope. > May I politely and respectfully suggest there are things about the > standardizing > Yang models that you have not asked about. > > The first stage of a yang model is joyous. You decide what goes in. The > second of getting a prototype yang model implementation is hard work. The > third stage of getting the model approved in the IETF environment is > frustrating and painful.During the second and third stage, most WGs have > trouble keeping up the energy - since it is all about the small details of > Yang. Help me understand how to read this progression as it relates to the I2NSF documents. What didn't I ask? > Tom Petch has been very helpful, but it is a long process to refactored > structures in Yang. Paul has done a tremendous job in both doing prototype > implementations, and working through the lengthy issues with the Yang > models. While completing those 5 models, Paul has run into many of the > structural issues/debates inside Yang. I couldn't agree with you more. Paul and Tom have a done a tremendous and admirable job on the core I2NSF data models. > Having struggle to incorporate yang models from IP-SEC into the BGP model > (with my excellent co-authors), may I suggest that even the IP-SEC models > are just at the beginning from I2NSF.Maybe there are other IP-SEC Yang > models outside of I2NSF. The community would know better than me on what future work is needed to better manage security protocols, IPSec, or otherwise with Yang modules. I don't see the I2NSF WG being the place to do that Yang work for security protocols in the general case. Roman > Sue > > -Original Message- > From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Roman Danyliw > Sent: Sunday, March 20, 2022 2:33 PM > To: i2nsf@ietf.org > Subject: [I2nsf] Comments on re-chartering > > Hi! > > It's nice to see I2NSF on the formal meeting agenda again. I see discussions > on > the mailing list to again revisit the WG charter [3] and it's on the agenda > for > this week's IETF 113 meeting. I don't want my position at the meeting to come > as a surprise so I'll restate what I've previously said in November 2020 [1] > and > October 2021 [2] on a new I2NSF charter: > > ** By all means, please use the WG to discuss I2NSF and the associated > ecosystem. > > ** With the degree of discussion and review demonstrated in the last two years > by the WG on I2NSF documents, these is not sufficient WG participation to take > on new work. It remains unclear if there is even enough energy to finish the > currently charted documents. Given the current WG dynamics, I will not > support a new charter. > > ** Rechartering the W
Re: [I2nsf] Comments on re-chartering
Roman: May I ask a questions before answering your questions. 1) How many security Yang models have been published? 2) How long does it take Yang models approved in the security area? 3) How many IETF yang models have been deployed? 4) Does the small deployment for IETF yang models change the value of the model? The SEC-ADs sent this WG off to create Yang models. Did you consider this in your review? May I politely and respectfully suggest there are things about the standardizing Yang models that you have not asked about. The first stage of a yang model is joyous. You decide what goes in. The second of getting a prototype yang model implementation is hard work. The third stage of getting the model approved in the IETF environment is frustrating and painful.During the second and third stage, most WGs have trouble keeping up the energy - since it is all about the small details of Yang. Tom Petch has been very helpful, but it is a long process to refactored structures in Yang. Paul has done a tremendous job in both doing prototype implementations, and working through the lengthy issues with the Yang models. While completing those 5 models, Paul has run into many of the structural issues/debates inside Yang. Having struggle to incorporate yang models from IP-SEC into the BGP model (with my excellent co-authors), may I suggest that even the IP-SEC models are just at the beginning from I2NSF.Maybe there are other IP-SEC Yang models outside of I2NSF. Sue -Original Message- From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of Roman Danyliw Sent: Sunday, March 20, 2022 2:33 PM To: i2nsf@ietf.org Subject: [I2nsf] Comments on re-chartering Hi! It's nice to see I2NSF on the formal meeting agenda again. I see discussions on the mailing list to again revisit the WG charter [3] and it's on the agenda for this week's IETF 113 meeting. I don't want my position at the meeting to come as a surprise so I'll restate what I've previously said in November 2020 [1] and October 2021 [2] on a new I2NSF charter: ** By all means, please use the WG to discuss I2NSF and the associated ecosystem. ** With the degree of discussion and review demonstrated in the last two years by the WG on I2NSF documents, these is not sufficient WG participation to take on new work. It remains unclear if there is even enough energy to finish the currently charted documents. Given the current WG dynamics, I will not support a new charter. ** Rechartering the WG would first require all previously promised deliverables (all 5 YANG modules) to be complete (at the RFC Editor), and then amongst other things, the identification of a critical mass of additional WG participants (beyond document authors/their organizations) committed to reviewing and implementing the work. Next steps would be heavily dependent on the specifics of the new work being proposed. To the specific charter text [3], a few high level questions: (a) This seems like a lot of work that equal to, if not larger than, the original WG scope which the WG is having difficulty finishing. Given that I2NSF has been unable to publish any of its core protocol deliverables in the last 6.5 years (chartered September 2015), is this the right size of new work to consider? Why is there bandwidth to do new work, but not finish the existing work? (b) This seems like a significant expansion into areas that I2NSF has not worked on -- DLT, PQ Crypto, attestation, etc. This begs questions such as whether a new WG is more appropriate. Why is I2NSF the right place? (c) Correct me if I'm wrong, it's my understanding that there isn't commercial adoption (or a substantial user base) of I2NSF yet. If that's true, what role will this new work play in increasing the likelihood of adoption? Why does this additional work have to happen now rather than waiting for more operational experience? Regards, Roman [1] https://mailarchive.ietf.org/arch/msg/i2nsf/FBzpXwPUaY5PkcgvKpWnHAAanp4/ [2] https://mailarchive.ietf.org/arch/msg/i2nsf/GAqtySDhTlhgPGMh_MdaajApUDs/ [3] https://mailarchive.ietf.org/arch/msg/i2nsf/XQxOoQS9JkJ0hDeICISHEl8QasE/ ___ 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
