Skip to main content

Archived Plans

On this page, you can find our plans from previous quarters and requests from the community. We update this page at the end of each quarter.

Q4 2023 Plans and Community Input

Plans
Item Activity Description
1

RPKI compliance project (ISAE3000)

We needed a well-recognised audit framework that both encompasses all important IT security elements and can be tailored towards the design principals and RFCs of RPKI. For this purpose, we want to develop an RPKI audit framework that can potentially also be used by other Trust Anchors. This is now an ISAE3000/SOC 2 Type II audit framework.

The tailored ISAE3000 control framework for RPKI was designed, and we completed a gap analysis against this framework. We are now in the process of further developing relevant documentation, implementing controls and gathering evidence for the first certification audit. After this, we will engage with known international audit firms to plan the execution of the first certification audit.

2

RPKI Dashboard improvements

We are working on the RPKI dashboard to improve its usability and extend its functionality with new object types. We have performed a user study of the existing dashboard and will use this as input for the next steps.

3

Open source "rpki-monitoring"

 

We will work on open-sourcing our internal RPKI monitoring that (1) compares if multiple rsync/rrdp repositories are in sync and (2) if objects are far enough from expiry.

4 New online HSMs

We have received new online Hardware Security Modules (HSMs). We will start migrating to these new HSMs after the vendor delivers an update for the custom library we use to store HSM-protected keys in a database.

5 ASPA profile 16 in pilot

We have support for Autonomous System Provider Authorization (ASPA) objects in the API of our pilot environment. The definition of the ASPA object structure has changed. We plan to update our implementation to support the new object structure.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and will add a reaction when ready.

RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and will add a reaction when ready.
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.
RPKI-2023-#01

Suggestion to add RSC support

We are aware of multiple use cases for RSC (e.g. proof of ownership of an ASN).

We will investigate the possibilities and will add a full reaction when ready.

RPKI-2023-#02

Known routing beacons with changing RPKI validity would help researchers.

We will support the team in implementing the routing beacons in the third quarter.

Q3 2023 Plans and Community Input

Plans
Item Activity Description
1

RPKI compliance project (ISAE3000)

We needed a well-recognised audit framework that both encompasses all important IT security elements and can be tailored towards the design principals and RFCs of RPKI. For this purpose, we want to develop an RPKI audit framework that can potentially also be used by other Trust Anchors. This is now an ISAE3000/SOC 2 Type II audit framework.

The tailored ISAE3000 control framework for RPKI has been designed, and a gap analysis against the framework has been completed. We are now in the process of further developing relevant documentation, implementing controls and gathering evidence for the first certification audit. In Q3, we will be engaging with known international audit firms to plan the execution of the first certification audit towards the end of the year.

2

RPKI Dashboard improvements

We are working on the RPKI dashboard to improve its usability and extend its functionality with new object types.

The first phase will be a re-implementation of the current dashboard with minor improvements. After this, we will do a redesign and add new object types.

3

rsync repository capability

We are aware of the capacity limitations of our rsync repositories. The rsync repositories are mainly used as a fallback during issues with RRDP. This quarter, we will work on increasing their capacity and resiliency.

4

Open source "rpki-monitoring"

 

We will work on open-sourcing our internal RPKI monitoring that (1) compares if multiple rsync/rrdp repositories are in sync and (2) if objects are far enough from expiry.

5 New online HSMs

We have received new online Hardware Security Modules (HSMs). We will start migrating to these new HSMs after the vendor delivers an update for the custom library we use to store HSM-protected keys in a database.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and will add a reaction when ready.

RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and will add a reaction when ready.
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.
RPKI-2023-#01

Suggestion to add RSC support

We are aware of multiple use cases for RSC (e.g. proof of ownership of an ASN).

We will investigate the possibilities and will add a full reaction when ready.

RPKI-2023-#02

Known routing beacons with changing RPKI validity would help researchers.

We will support the team in implementing the routing beacons in the third quarter.

Q2 2023 Plans and Community Input

Plans
Item Activity Description
1

RPKI compliance project (ISAE3000)

We needed a well-recognised audit framework that both encompasses all important IT security elements and can be tailored towards the design principals and RFCs of RPKI. For this purpose, we want to develop an RPKI audit framework that can potentially also be used by other Trust Anchors. This is now an ISAE3000/SOC 2 Type II audit framework.

We are now in the process of gathering evidence for our audit. In 2023, we will first start with an assessment of the framework by a third party. Because ISAE3000/SOC 2 Type II frameworks are free-form by nature, we want to ensure that we have the right controls and evidence in place.

2

RPKI Dashboard improvements

We will work on the RPKI dashboard to improve its usability and extend its functionality with new object types.

3

rsync repository capability

We are aware of the capacity limitations of our rsync repositories. The rsync repositories are mainly used as a fallback during issues with RRDP. This quarter, we will work on increasing their capacity and resiliency.

4 New online HSMs

We have received new online Hardware Security Modules (HSMs). After our vendor does the prerequisite work, we will work on migrating to these new HSMs.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and will add a reaction when ready.

RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and will add a reaction when ready.
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.
RPKI-2023-#01

Suggestion to add RSC support

We are aware of multiple use cases for RSC (e.g. proof of ownership of an ASN).

We will investigate the possibilities and will add a full reaction when ready.

Q1 2023 Plans and Community Input

Plans
Item Activity Description
1 Create multiple parallel internal test environments for RPKI

Work started in Q1 2022 and was completed in Q1 2023.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

2

Request to implement "Publish in Parent" RFC 8181 support.

Work started in Q1 2022 and was completed in Q1 2023.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations that choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

This feature was requested by Benno Overeinder in the Routing WG session of RIPE 82 as well as by Job Snijders on the routing-wg mailing list in September 2021.

We are currently doing an "open beta trial", and the full launch will be in mid-January 2023.

We have marked this with reference RPKI-2021-#3 in the table below

3

RPKI compliance project (ISAE3000)

Work started in Q1 2023.

We needed a well-recognised audit framework that both encompasses all important IT security elements and can be tailored towards the design principals and RFCs of RPKI. For this purpose, we want to develop an RPKI audit framework that can potentially also be used by other Trust Anchors. This is now an ISAE3000/SOC 2 Type II audit framework.

We are now in the process of gathering evidence for our audit. In 2023, we will first start with an assessment of the framework by a third party. Because ISAE3000/SOC 2 Type II frameworks are free-form by nature, we want to ensure that we have the right controls and evidence in place.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and add a reaction when ready.

RPKI-2021-#03

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Completed

RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and add a reaction when ready.

RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.

Q4 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

Work started in Q1 2022 and was completed in Q4 2022.

In 2022, we will perform a Red Team security exercise for RPKI. A Red Team assessment is an ultimate test by an external party trying to access our systems and data through different means, such as phishing or getting physical access to our data. The exact timeline for this exercise is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

2 Create multiple parallel internal test environments for RPKI

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

3

Pilot ASPA support

Work started in Q1 2022 and was completed in Q4 2022.

Autonomous System Provider Authorization (ASPA) is an active draft (a current proposal) in the IETF sidrops working group. ASPA objects describe the provider relations for an AS number. We will provide input to the discussion by producing some code on a testbed.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

We are investigating possibilities here and add a reaction when ready.

RPKI-2021-#03

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

The activity was on hold and will launch in mid-January 2023.

RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

We are investigating possibilities here and add a reaction when ready.

RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

We are waiting for an internal SSO project to be completed, and we will add a reaction when ready.

Q3 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

Work started in Q1 2022.

In 2022, we will perform a Red Team security exercise for RPKI. A Red Team assessment is an ultimate test by an external party trying to access our systems and data through different means, such as phishing or getting physical access to our data. The exact timeline for this exercise is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

2 Implement "Publish in Parent" RFC 8181 support

Work started in Q1 2022 and was placed on due to pending approval of new terms and conditions and further technical work.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations that choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

This feature was requested by Benno Overeinder in the Routing WG session of RIPE 82 as well as by Job Snijders on the routing-wg mailing list in September 2021.

We have marked this with reference RPKI-2021-#3 in the table below.

3 Create multiple parallel internal test environments for RPKI

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

4 Improve the internal business logic on certifiable resources

Work started in Q1 2022.

The registry software dictated whether resources were eligible for certification, and the RPKI software followed the registry software. We have improved the registry software to allow atomic reads of registry state and will support the registry software team with changes where needed.

5

Pilot ASPA support

Work started in Q1 2022.

Autonomous System Provider Authorization (ASPA) is an active draft (a current proposal) in the IETF sidrops working group. ASPA objects describe the provider relations for an AS number. We will provide input to the discussion by producing some code on a testbed.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

 
RPKI-2021-#03

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Currently on hold due to pending approval of new terms and conditions and further technical work (item 2 above).

RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

 
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

 
RPKI-2021-#06

Move delegated CAs communication (“up-down”) to TLS out of precaution.

For more information, check the Routing WG mailing list archives.

After further discussion, a decision has been made not to move ahead with this request.

Q2 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

Work started in Q1 2022.

In 2022, we will perform a Red Team security exercise for RPKI. A Red Team assessment is an ultimate test by an external party trying to access our systems and data through different means, such as phishing or getting physical access to our data. The exact timeline for this exercise is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

2 Implement "Publish in Parent" RFC 8181 support

Work started in Q1 2022 and was placed on due to pending approval of new terms and conditions and further technical work.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations that choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

This feature was requested by Benno Overeinder in the Routing WG session of RIPE 82 as well as by Job Snijders on the routing-wg mailing list in September 2021.

We have marked this with reference RPKI-2021-#3 in the table below.

3 Create multiple parallel internal test environments for RPKI

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

4 Improve the internal business logic on certifiable resources

Work started in Q1 2022.

The registry software dictated whether resources were eligible for certification, and the RPKI software followed the registry software. We have improved the registry software to allow atomic reads of registry state and will support the registry software team with changes where needed.

5

Pilot ASPA support

Work started in Q1 2022.

Autonomous System Provider Authorization (ASPA) is an active draft (a current proposal) in the IETF sidrops working group. ASPA objects describe the provider relations for an AS number. We will provide input to the discussion by producing some code on a testbed.

6

Create a public status page

Work started in Q3 2021.

We have been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI.

The page has been published and is available at:

https://status.ripe.net

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning.

See item 6 in the table above.

Completed

RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

 
RPKI-2021-#03

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

See item 2 in the table above.
RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

 
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

 
RPKI-2021-#06

Move delegated CAs communication (“up-down”) to TLS out of precaution.

For more information, check the Routing WG mailing list archives.

 

Q1 2022 Plans and Community Input

Plans
Item Activity Description
1 Support a Red Team security exercise

Work started in Q1 2022.

In 2022, we will perform a Red Team security exercise for RPKI. A Red Team assessment is an ultimate test by an external party trying to access our systems and data through different means, such as phishing or getting physical access to our data. The exact timeline for this exercise is confidential by nature, but this is an important step towards improving security for RPKI and the RIPE NCC.

2 Implement "Publish in Parent" RFC 8181 support

Work started in Q1 2022.

ARIN and APNIC have already indicated that they would offer this service to Delegated RPKI users. We are now working on offering this service too. Organisations which choose to run their own CA will have the option to publish their RPKI objects in repositories provided by the RIPE NCC. We believe this will help improve the resiliency of the RPKI ecosystem.

This feature was requested by Benno Overeinder in the Routing WG session of RIPE 82 as well as by Job Snijders on the routing-wg mailing list in September 2021.

We have marked this with reference RPKI-2021-#3 in the table below.

3 Create multiple parallel internal test environments for RPKI

Work started in Q1 2022.

Currently, the RPKI team shares one environment used for Quality Assurance. This shared environment leads to longer release cycles as we can not independently evaluate multiple features in parallel. We will set up multiple independent environments (with one environment per feature if possible). Having more environments available will allow us to evaluate features independently and improve our Q&A and release process.

4 Improve the internal business logic on certifiable resources

Work started in Q1 2022.

The registry software dictated whether resources were eligible for certification, and the RPKI software followed the registry software. We have improved the registry software to allow atomic reads of registry state and will support the registry software team with changes where needed.

5

Pilot ASPA support

Work started in Q1 2022.

Autonomous System Provider Authorization (ASPA) is an active draft (a current proposal) in the IETF sidrops working group. ASPA objects describe the provider relations for an AS number. We will provide input to the discussion by producing some code on a testbed.

6 Scaling up the RPKI repositories

Work was completed in Q1 2022.

As part of our improvements to the RPKI repository infrastructure, the RRDP publication server will be deployed on-premise. This greatly simplifies transitioning between instances of the publication server without any
downtime. The infrastructure is now in place, but we still need to finalise some
technical work to serve the data hosted on premise.

Note: We are not referring to cloud technologies here, just to our internal
deployment technologies.

7

Create a public status page

Work was completed in Q2 2022.

We have been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning.

See item 7 in the table above.

RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

 
RPKI-2021-#03

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

See item 2 in the table above.
RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

 
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

 
RPKI-2021-#06

Move delegated CAs communication (“up-down”) to TLS out of precaution.

For more information, check the Routing WG mailing list archives.

 

Q4 2021 Plans and Community Input

Plans
Item Activity Description
1 Implement and publish findings of the penetration test report

Work was completed in Q4 2021.

Radically Open Security (ROS) performed a penetration test of the LIR Portal and the RPKI infrastructure. ROS identified nine issues which we resolved in Q4 2021.

You can find more details in the published report.

2 Implement findings of the source code review and open source the RPKI core

Work was completed in Q4 2021.

Radically Open Security (ROS) performed a source code review in preparation to open source the RPKI core. The goal of this review was to assess what parts of the code needed to be updated before we could Open Source this code, and make it available to the wider community.

ROS identified eight issues that were resolved in Q4 2021. You can find more details in the published report.

3 New Hardware Security Module (HSM)

Work took place from Q3 2021 until Q4 2021.

We were using both online and offline HSMs for our Trust Anchor. The offline HSM was at the end-of-life and has been replaced.

4 Scaling up the RPKI repositories

Work took place from Q3 2021 until Q1 2022.

As part of our improvements to the RPKI repository infrastructure, the RRDP publication server will be deployed on-premise. This greatly simplifies transitioning between instances of the publication server without any downtime. The infrastructure is now in place, but we still need to finalise some technical work to serve the data hosted on premise.

Note: We are not referring to cloud technologies here, just to our internal deployment technologies.

5

Create a public status page

Work was completed in Q2 2022.

We had been asked at the RIPE 82 presentation on RPKI to create a public status page for RPKI.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning. See item 5 in the table above.
RPKI-2021-#02

Request to add BGPsec support in Hosted RPKI.

For more information, check the Routing WG mailing list archives.

 
RPKI-2021-#03

Request to implement "Publish in Parent" RFC 8181 support.

For more information, check the Routing WG mailing list archives.

Added to our Q1 2022 planning.
RPKI-2021-#04

Request to add real-time metrics and status updates of alerts or subsections to a feed.

For more information, read the Q&A section of the RIPE NCC RPKI Update at RIPE 83 (presentation no.4).

 
RPKI-2021-#05

Suggestion to allow 3rd party access to the LIR Portal to make RPKI changes.

 

Q3 2021 Plans and Community Input

Plans
Item Activity Description
1 End of support for the RIPE NCC RPKI Validator

Work was completed in Q3 2021.

On 1 July 2021, we ended offering support for the RIPE NCC RPKI Validator. Our RPKI Validator is one of several Relying Party software that network operators can use to download and validate the global RPKI data set. This data is used to support their BGP decision making process.

We also migrated the user interface of the rpki-validator.ripe.net from the RIPE NCC RPKI Validator 2 to Routinator.

More information has been shared on RIPE Labs and at our presentation at RIPE 81.

2 SOC 2 Type II audit framework

Work was completed in Q3 2021.

We designed an RPKI audit framework that allows us to publish a transparent SOC 3 report of our findings. In Q1 2021, we worked with the British Standards Institution to identify missing controls and we worked towards closing these gaps.

We have collected all the evidence to fulfill the controls of the SOC 2 type 2 RPKI framework. The audit will take place in Q2 2022.

3 Open sourcing the RPKI core

Work was completed in Q3 2021.

Radically Open Security (ROS) performed a code review of the RPKI Core. The goal of this review was to assess what parts of the code need to be updated before we can Open Source this code, and make it available to the wider community.

The report was delivered on 19 July 2021.

4 Penetration testing

Work was completed in Q3 2021.

We have asked ROS to perform a pen test on our RPKI Core, RPKI Commons and the RPKI Dashboard.

The report was delivered on 26 July 2021.

5

Scaling up the RPKI repositories

Work took place from Q3 2021 until Q1 2022.

In preparation for the improved RPKI repository architecture, the distributed nature of the RRDP repository is going to be implemented using containers and krill-sync that pulls data from the centralised on-premise repository. This greatly simplifies smooth transitioning between publication servers without any downtime.

NOTE: We are not referring to cloud technologies here, just to our internal deployment technologies.

6 New Hardware Security Module (HSM)

Work took place from Q3 2021 until Q4 2021.

We were using both online and offline HSMs for our Trust Anchor. The offline HSM was at the end-of-life and has been replaced.

Community Input
Reference Input RIPE NCC Reaction
RPKI-2021-#01 Request to add public status page (as referenced during RIPE 82 RPKI presentation) to the RPKI planning. Added to our Q4 2021 planning.