Epäilykseni oikeastaan kohdistui siihen, mikä on RINAn suhde noihin kysymyksiin, jotka on joka tapauksessa ratkaistava ja jotka käytännössä varsin pitkälle ratkaisevat niitä TCP/IP-maailman ongelmia, joita RINA ilmeisesti yrittää ratkaista alemman tason protokollakerroksilla (minkä epäilen vaikeuttavan joustavuuden ja luotettavuuden yhdistämistä, vaikkain saatan olla vain ennakkoluuloinen).
Termi alemman tason protokollakerros on epätarkka, koska RINAssa on vain yksi kerros, jota monistetaan päällekkäin ja rinnakkain niin paljon kuin on tarpeen. Jokaisella voi olla eri maantieteellinen alue, jossa kerros leviää, mutta rakenne on kaikissa sama.
RINAssakin data kryptataan end-to-end-periaatteella, joten periaatteessa samat mekanismit joita nyt käytetään toimivat myös siinä. Jos verkko on kryptattu, ei mikään sitä reitittävä laite näe sen sisälle. Reitittimien tehtäväksi pääsyrajoitusten suhteen jää tarkistaa, onko paketin digitaalinen allekirjoitus validi vai ei; jos on niin reititetään eteenpäin, jos ei niin heitetään roskiin.
Tietoturva ei todellakaan ole ainoa asia, jota RINA parantaisi. Esimerkiksi energiatehokkuusvaatimuksiin on vaikea vastata nykyverkolla, kun reititettäviä prefixejä on miljoonia, ja lisää tulee koko ajan IPv6:n ja erilaisten tunnelointi-purkkaviritysten myötä. Karrikoituna esimerkkinä voisi sanoa, että RINAssa ylimmän tason reititystaulussa on viisi mannerta, seuraavassa mantereen valtiot eli joitain kymmeniä, seuraavassa valtion maakunnat jne. Esimerkki ei ole kovin tarkka tai välttämättä realistinenkaan, mutta kertoo karrikoidusti millaisesta edusta puhutaan. Reitittimien prosessoritehon (ja siten myös energian) tarpeen ero IP-tekniikkaan nähden ei ole yksi tai kaksi dekadia, vaan paljon enemmän.
RINA myös yksinkertaistaisi asioita valtavasti, koska puhtaassa toteutuksessa tarvitaan vain kaksi protokollaa nykyisten tuhansien sijaan (toki RINA voi myös kantaa sisällään nykyisiä sovellusprotokollia ja myös IP-paketteja). Tähän suuntaanhan toki ollaan menossa jo nyt IP-maailmassakin, kun kirjainyhdistelmä JSON + HTTP + QUIC + UDP valtaa alaa. Yleensäkin REST-rajapintojen yleistyminen ja erilaiset RPC-ratkaisut lisääntyvät, mikä on hyvä - porukka on tajunnut ettei pyörää tarvitse keksiä joka kerta uudelleen, kun tehdään uusi sovellus joka tarvitsee verkkokommunikaatiota. Silti edelleen yllättävän monesti näyttäisi ratkaisu uuden sovelluksen kommunikaatiotarpeisiin olevan uusi protokolla.
