content: Fix i2cat http link

1 files changed, 18 insertions, 18 deletions

diff --git a/content/en/blog/20210320-ouroboros-rina.md b/content/en/blog/20210320-ouroboros-rina.md
index da9e178..3b3940d 100644
--- a/content/en/blog/20210320-ouroboros-rina.md
+++ b/content/en/blog/20210320-ouroboros-rina.md
@@ -52,7 +52,7 @@ of FIRE are "hands-on", aimed at building and deploying Internet
 technologies. Given that I had some experience deploying experiments
 (at that time OpenFlow prototypes) on our lab testbeds, I listened to
 the project pitch, an online presentation with Q&A given by the
-project lead, Eduard Grasa from [i2cat]((https://i2cat.net/)), who
+project lead, Eduard Grasa from [i2cat](https://i2cat.net/), who
 explained the concepts behind RINA, and got quite excited about how
 elegant this all looked. So I took on the project and read John Day's
 [Patterns in Network Architecture](https://www.oreilly.com/library/view/patterns-in-network/9780132252423/),
@@ -489,23 +489,23 @@ was also becoming available at the time and would be used in
 ARCFIRE. And soon, the development of a third prototype -- _ouroboros_
 -- would start. External perception of RINA in the scientific
 community had also been shifting, and not in a positive direction. At
-the start of the project, we had the position paper with project plans
-and outlines, and the papers on the _shims_ showed some ways on how
-RINA could be deployed. But other articles trying to demonstrate the
-benefits of RINA were -- despite all the efforts and good will of all
-people involved -- lacking in quality, mostly due to the limitations
-of the software. All these subpar publications did more harm than
-good, as the quality of the publications rubbed off on the perceived
-merits of the RINA architecture as a whole. We were always feeling
-this pressure to publish _something_, _anything_ -- and reviewers were
-always looking for a value proposition -- _Why is this better than my
-preferred solution?_, _Compare this in depth to my preferred solution_
--- that we simply couldn't support with data at this point in
-time. And not for lack of want or a lack of trying. But at least,
-ARCFIRE had at 2 years to look forward to, a focused scope and by now,
-the team had a lot of experience in the bag. But for the future of
-RINA, we knew the pressure was on -- this was a _now or never_ type of
-situation.
+the start of the IRATI project, we had the position paper with project
+plans and outlines, and the papers on the _shims_ showed some ways on
+how RINA could be deployed. But other articles trying to demonstrate
+the benefits of RINA were -- despite all the efforts and good will of
+all people involved -- lacking in quality, mostly due to the
+limitations of the software. All these subpar publications did more
+harm than good, as the quality of the publications rubbed off on the
+perceived merits of the RINA architecture as a whole. We were always
+feeling this pressure to publish _something_, _anything_ -- and
+reviewers were always looking for a value proposition -- _Why is this
+better than my preferred solution?_, _Compare this in depth to my
+preferred solution_ -- that we simply couldn't support with data at
+this point in time. And not for lack of want or a lack of trying. But
+at least, ARCFIRE had at 2 years to look forward to, a focused scope
+and by now, the team had a lot of experience in the bag. But for the
+future of RINA, we knew the pressure was on -- this was a _now or
+never_ type of situation.
 
 ### Ouroboros