Subject: [I2nsf] Comments on re-chartering

From: Roman Danyliw <[email-masked]>
Date: Sun, 20 Mar 2022 18:33:17 +0000

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/

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Mar 2022 15:12:22 -0400

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:[email-masked]] On Behalf Of Roman Danyliw
Sent: Sunday, March 20, 2022 2:33 PM
To: [email-masked]
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.

(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

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Roman Danyliw <[email-masked]>
Date: Sun, 20 Mar 2022 21:02:39 +0000

Hi Sue!

> From: I2nsf <[email-masked]> On Behalf Of Susan Hares
> Sent: Sunday, March 20, 2022 3:12 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: [I2nsf] Comments on re-chartering
> 
> Roman:
> 

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

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

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.
> 

Help me understand how to read this progression as it relates to the I2NSF documents.  What didn't I ask?

> 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.

> are just at the beginning from I2NSF.    Maybe there are other IP-SEC Yang

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

> 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:
> 
> ** 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.
> 
> (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/
>

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 20 Mar 2022 22:31:21 +0000

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: [email-masked]
Mobile:  +34 682 051 091
----------------------------------

On 20/03/2022, 22:03, "I2nsf on behalf of Roman Danyliw" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Sue!

    Roman

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 20 Mar 2022 18:34:56 -0400

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:[email-masked]] 
Sent: Sunday, March 20, 2022 5:03 PM
To: Susan Hares; [email-masked]
Subject: RE: [I2nsf] Comments on re-chartering

Hi Sue!

> 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

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

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
> trouble keeping up the energy - since it is all about the small details of

Help me understand how to read this progression as it relates to the I2NSF
documents.  What didn't I ask?

> 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.

> are just at the beginning from I2NSF.    Maybe there are other IP-SEC Yang

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

> It's nice to see I2NSF on the formal meeting agenda again.  I see
discussions on
> ** With the degree of discussion and review demonstrated in the last two
years
> ** Rechartering the WG would first require all previously promised
deliverables
> (a) This seems like a lot of work that equal to, if not larger than, the
original
> (b) This seems like a significant expansion into areas that I2NSF has not
worked
> (c) Correct me if I'm wrong, it's my understanding that there isn't
commercial

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 22 Mar 2022 10:54:29 +0000

Hi Sue!

> From: Susan Hares <[email-masked]>
> Sent: Sunday, March 20, 2022 6:35 PM

...

> 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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 08:46:25 -0400

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:[email-masked]] On Behalf Of Roman Danyliw
Sent: Tuesday, March 22, 2022 6:54 AM
To: Susan Hares; [email-masked]
Subject: Re: [I2nsf] Comments on re-chartering

Hi Sue!

...

> 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

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

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 23 Mar 2022 13:20:24 +0000

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

> Sent: Wednesday, March 23, 2022 8:46 AM
> 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.
> 
> > use it in the BGP model.  This takes chatting with the folks in I2NSF
> > who
> are
> > experts.
> 
> 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
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 09:26:49 -0400

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:[email-masked]] 
Sent: Wednesday, March 23, 2022 9:20 AM
To: Susan Hares; [email-masked]
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

> closely align this activity with the larger critical mass of work in Yang
modules

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 23 Mar 2022 13:50:56 +0000

Hi Sue!

> Sent: Wednesday, March 23, 2022 9:27 AM
> 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

Wonderful.

Regards,
Roman

> understanding of that scope, where this work should be done could also occur.
> 
> 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
> 
> 
> > 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.
> >
> > > use it in the BGP model.  This takes chatting with the folks in
> > > I2NSF who
> > are
> > > experts.
> >

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 23 Mar 2022 09:54:00 -0400

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:[email-masked]] On Behalf Of Roman Danyliw
Sent: Wednesday, March 23, 2022 9:51 AM
To: Susan Hares; [email-masked]
Subject: Re: [I2nsf] Comments on re-chartering

Hi Sue!

> 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.

Wonderful.

Regards,
Roman

occur.
> work.  However, the flexibility I exercised to ensure that it didn't get
orphaned
> > > experience with the lengthy cycle for this work.   Ask Rob Wilton
about
> > the

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Mar 2022 22:33:58 +0100

On Mar 23, 2022, at 13:47, Susan Hares <[email-masked]> wrote:
> 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

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Mar 2022 03:18:14 -0400

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:[email-masked]] 
Sent: Wednesday, March 23, 2022 5:34 PM
To: Susan Hares
Cc: Roman Danyliw; [email-masked]
Subject: Re: [I2nsf] Comments on re-chartering

On Mar 23, 2022, at 13:47, Susan Hares <[email-masked]> wrote:
> 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 be "cross-area" participant of I2NSF to see that 
> these definitions get thought through by both types of people.

Paul

---

From: t petch <[email-masked]>
Date: Thu, 24 Mar 2022 11:22:07 +0000

> 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…

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.

> .

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Mar 2022 07:53:02 -0400

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:[email-masked]] On Behalf Of t petch
Sent: Thursday, March 24, 2022 7:22 AM
To: Roman Danyliw; Susan Hares; [email-masked]
Subject: Re: [I2nsf] Comments on re-chartering

On 22/03/2022 10:54, Roman Danyliw wrote:
>> 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.