Spett.le Amministrazione,

con riferimento al documento “Allegato C – Modello di offerta economica”, e in particolare all'obbligo di assolvimento del bollo legale di € 16,00, si chiede cortesemente di confermare che tale adempimento possa essere assolto mediante l'acquisto di una marca da bollo di pari importo, allegando all'offerta copia del relativo contrassegno in formato PDF e assumendo ogni responsabilità in merito all'eventuale utilizzo plurimo dello stesso.

Si resta in attesa di cortese riscontro.

Lotto 1, 5.2 Requisiti Generali
Si chiede se il requisito relativo al Supporto multi-protocollo comprensivo di accesso a blocchi (block protocol) si intenda soddisfatto qualora la soluzione offerta supporti nativamente il protocollo NVMe-oF, trattandosi del più moderno standard di mercato per lo storage a blocchi ad altissime prestazioni e bassa latenza, che di fatto evolve e supera le limitazioni del protocollo legacy iSCSI pur operando sulla medesima infrastruttura di rete.

PUNTO 1 - FATTURATO: ’MIGLIORI TRE ANNI DEGLI ULTIMI CINQUE’ (DISCIPLINARE) VS ’TRIENNIO PRECEDENTE’ (DGUE)


Si riscontra una discordanza tra:


• Disciplinare di gara: “[Sezione 6.2 - Requisiti di capacità economica e finanziaria Lotto 1] Fatturato globale maturato nei migliori tre anni degli ultimi cinque precedenti a quello in cui è stata pubblicata la gara, almeno pari a € 5.000.000,00 (iva esclusa). [Sezione 6.2 - Requisiti di capacità economica e finanziaria Lotto 2] Fatturato globale maturato nei migliori tre anni degli ultimi cinque precedenti a quello in cui è stata pubblicata la gara, almeno pari a € 500.000,00 (iva esclusa).”


• Modello DGUE (Allegato A1): “Capacità economica e finanziaria - Fatturato globale nel triennio precedente [Art. 100, comma 11 del Codice] - “Il fatturato globale maturato nel triennio precedente a quello di indizione della procedura è il seguente (art. 100, comma 11, del Codice)””


Si chiede pertanto alla Stazione Appaltante di voler chiarire: Il Disciplinare (art. 6.2) richiede il fatturato globale ’maturato nei migliori tre anni degli ultimi cinque precedenti a quello in cui è stata pubblicata la gara’, mentre il modello DGUE (Parte IV, Sezione B) richiede ’il fatturato globale maturato nel triennio precedente a quello di indizione della procedura’. Si chiede di confermare quale sia il periodo di riferimento corretto per la dichiarazione del fatturato globale nel DGUE: se il concorrente debba indicare i dati relativi ai tre anni migliori scelti nell’arco del quinquennio (come previsto dal Disciplinare) oppure il triennio fisso immediatamente precedente all’anno di pubblicazione della gara.




PUNTO 2 - FORNITURE ANALOGHE: ’ULTIMI DIECI ANNI’ (DISCIPLINARE) VS ’PRECEDENTE TRIENNIO’ (DGUE)


Si riscontra una discordanza tra:


• Disciplinare di gara: “[Sezione 6.3 - Requisiti di capacità tecnico-professionale Lotto 1] Esecuzione negli ultimi dieci anni di almeno una fornitura analoga a quella oggetto del Lotto 1, di importo non inferiore a € 5.000.000,00 (iva esclusa). Per fornitura analoga si intende una fornitura di un sistema di storage all-flash di capacità non inferiore a 5 PB. [Sezione 6.3 - Requisiti di capacità tecnico-professionale Lotto 2] Esecuzione negli ultimi dieci anni di almeno una fornitura analoga a quella oggetto del Lotto 2 di importo non inferiore a € 500.000,00 (iva esclusa).”


• Modello DGUE (Allegato A1): “Capacità tecniche e professionali [Art. 100, comma 1, lettera c) del Codice] - Contratti analoghi nel precedente triennio per forniture e servizi [Art. 100, comma 11 del Codice]: “di aver eseguito nel precedente triennio dalla data di indizione della procedura di gara contratti analoghi a quello in affidamento anche a favore di soggetti privati””


Si chiede pertanto alla Stazione Appaltante di voler chiarire: Il Disciplinare (art. 6.3) richiede l’esecuzione di almeno una fornitura analoga ’negli ultimi dieci anni’, mentre il modello DGUE (Parte IV, Sezione C) richiede la prova di aver eseguito contratti analoghi ’nel precedente triennio dalla data di indizione della procedura di gara’. Si chiede di confermare quale sia il periodo di riferimento corretto per la dichiarazione delle forniture analoghe nel DGUE: se il concorrente debba indicare forniture eseguite negli ultimi dieci anni (come previsto dal Disciplinare) oppure solo quelle del triennio precedente.




PUNTO 3 - TERMINE ELIMINAZIONE VIZI: 30 GIORNI LAVORATIVI (CAPITOLATI) VS 30 GIORNI SOLARI (SCHEMA DI CONTRATTO)


Si riscontra una discordanza tra:


• Capitolato Tecnico Lotto 1 (Sez. 9.3.1) e Lotto 2 (Sez. 8): “Nel caso di esito negativo, il Fornitore dovrà eliminare, entro ulteriori 30 giorni lavorativi, i vizi accertati.”


• Schema di Contratto (Art. 17.5): “Qualora le verifiche tecniche non dessero esito positivo l’Appaltatore dovrà eliminare, entro ulteriori 30 giorni solari, i vizi accertati e, all’esito delle attività di eliminazione di vizi e difetti, i test saranno ripetuti”


Si chiede pertanto alla Stazione Appaltante di voler chiarire: Si chiede alla Stazione Appaltante di confermare quale sia il termine applicabile per l’eliminazione dei vizi accertati in sede di verifica di conformità con esito negativo: 30 giorni lavorativi come indicato nei Capitolati Tecnici (Lotto 1, Sez. 9.3.1; Lotto 2, Sez. 8) ovvero 30 giorni solari come indicato nello Schema di Contratto (Art. 17.5), e di rettificare il documento difforme.




PUNTO 4 - ANTICIPAZIONE CONTRATTUALE 20%: PRESENTE NELLO SCHEMA DI CONTRATTO, NON MENZIONATA NEL DISCIPLINARE


Si riscontra una discordanza tra:


• Schema di Contratto (Art. 8.1): “[Art. 8.1] La fatturazione delle prestazioni rese dall’Appaltatore avverrà secondo le seguenti modalità: 20% dell’importo contrattuale a titolo di anticipazione contrattuale ex art. 125 D.Lgs. 36/2023, subordinata alla costituzione di apposita garanzia fideiussoria bancaria o assicurativa conforme alle prescrizioni di cui al predetto articolo”


• Disciplinare di gara (Sezioni 3.2 e 3.3): “[Sezione 3.2 - Revisione prezzi] Non applicabile, avente l’appalto ad oggetto una prestazione ad esecuzione istantanea e il cui prezzo non è determinato sulla base di indicizzazione. [Sezione 3.3 - Modifica del contratto in fase di esecuzione] Non è prevista alcuna modifica”


Si chiede pertanto alla Stazione Appaltante di voler chiarire: Si chiede di confermare che l’anticipazione contrattuale del 20% prevista all’art. 8.1 dello Schema di Contratto sia applicabile a entrambi i lotti e di specificare le condizioni della garanzia fideiussoria richiesta a copertura dell’anticipazione (importo, durata, soggetti legittimati al rilascio), nonché i termini di erogazione dalla stipula del contratto.




PUNTO 5 - TERMINE VERIFICA CONFORMITÀ: 30 GIORNI LAVORATIVI (CAPITOLATI) VS 30 GIORNI NON SPECIFICATI (SCHEMA DI CONTRATTO)


Si riscontra una discordanza tra:


• Capitolato Tecnico Lotto 1 e Lotto 2 (Sez. 9): “[Sez. 9 - Verifica conformità ed accettazione] Per tali verifiche è previsto un tempo massimo di 30 (trenta) lavorativi”


• Schema di Contratto (Art. 17.4): “[Art. 17.4] A seguito dei predetti adempimenti verranno eseguite le attività connesse alla verifica di conformità sulla base dei test e delle verifiche meglio specificate all’interno del Capitolato per verificare la corretta esecuzione di tutte le attività affidate nonché lo stato di funzionamento dei sistemi di calcolo e storage nel loro complesso, che dovranno essere eseguite entro 30 giorni”


Si chiede pertanto alla Stazione Appaltante di voler chiarire: Si chiede di confermare se il termine di 30 giorni previsto all’art. 17.4 dello Schema di Contratto per l’esecuzione delle verifiche di conformità sia da intendersi come giorni lavorativi (come indicato nei Capitolati Tecnici Lotto 1 e Lotto 2) o come giorni solari, anche al fine di determinare correttamente la data di esigibilità del saldo finale del 30% dell’importo contrattuale.




PUNTO 6 - RIDUZIONE DELLA GARANZIA PROVVISORIA EX ART. 106, COMMA 8: RIFERIMENTO ALLO STANDARD ISO 9001 / ISO 9000, CERTIFICAZIONI DELL'ALLEGATO II.13 E CUMULABILITÀ


Con riferimento alla Sezione 10 del Disciplinare, che disciplina le riduzioni dell’importo della garanzia provvisoria ai sensi dell’art. 106, comma 8, del D.Lgs. 36/2023, si osserva che la lett. a) subordina la riduzione del 30% al possesso della “certificazione di qualità conforme alle norme europee della serie UNI CEI ISO 9001”, mentre l’art. 106, comma 8, primo periodo, del Codice fa riferimento alla “serie UNI CEI ISO 9000”. Si chiede pertanto di chiarire:


a) se l’indicazione dello standard “UNI CEI ISO 9001” contenuta nella lett. a) costituisca un refuso e se la Stazione Appaltante intendesse in realtà richiamare lo standard “UNI CEI ISO 9000”, come previsto dal testo dell’art. 106, comma 8, del Codice;


b) se sia comunque volontà della Stazione Appaltante autorizzare la riduzione in caso di possesso della certificazione di qualità secondo lo standard UNI EN ISO 9001:2015, come espressamente individuata nell’Allegato II.13 del Codice, e, in caso affermativo, di confermare la percentuale di riduzione ammessa e se tale riduzione sia cumulabile con la riduzione del 50% prevista alla lett. b) della medesima Sezione 10 a favore delle micro, piccole e medie imprese. In caso affermativo, si chiede altresì di confermare se possano concorrere alla riduzione massima del 20% prevista dall’Allegato II.13 anche il possesso delle certificazioni UNI CEI EN ISO/IEC 27001, UNI EN ISO 14001, UNI ISO 45001 e UNI/PdR 125;


c) in caso di partecipazione alla gara in forma di raggruppamento temporaneo di imprese (RTI), se il possesso delle suddette certificazioni e dei relativi requisiti, ai fini del riconoscimento delle riduzioni, debba sussistere in capo a tutti i componenti del raggruppamento oppure se sia sufficiente che ne sia in possesso anche uno soltanto di essi.

LOTTO 2, 4.2 Obiettivi Operativi, Tabella 1

Par. 4.2 tabella 1, Capitolato Tecnico Lotto 2, si chiede di specificare meglio i seguenti punti:

A. Si chiede conferma che gli hypervisor sul quale risiedono le 80 VM elencate siano VMware e Proxmox.

B. Si richiede di poter avere maggiori dettagli relativi alla tipologia dati categorizzati come SIEM. In particolare a quanto ammonti al quantità di dati relativa al DB.

C. Per i 20 TB di dati users home file si chiede di specificare se siano erogati da sistemi virtualizzati, sistemi fisici o da sistemi NAS specifici.

D. Per i 60 TB di dati aggregati per server fisici linux, quanta parte è dato non strutturato (es : files, file system, log, export) e quanta parte è riconducibile a dato strutturato (DB )?

E. Par 4.7, Capitolato Tecnico Lotto 2, relativamente al collegamento alle reti dati, si chiede si specificare se andranno forniti transceivers a 10 gbit soltanto o in grado eventualmente di lavorare a 25 Gbit, per garantire la corretta negoziazione con le porte degli switch esistenti esterni alla attuale fornitura.

F. Par 4.8, Capitolato Tecnico Lotto 2, rispetto al punto Replica e DR si chiede conferma se la soluzione debba riferirsi specificatamente al backup/ripristino dei dati protetti, in caso di problemi al sito di produzione.

LOTTO 2

Quesito A.
Con riferimento al §4.3 del Capitolato Tecnico del Lotto 2, che richiede che il sistema di backup sia dotato di «componenti ridondanti e hot-swap (controller, dischi, alimentatori, ventole) per garantire continuità di servizio anche in presenza di guasti hardware», e considerato che la finalità espressamente indicata dal requisito è la continuità di servizio e la disponibilità del dato di backup in presenza di guasti hardware, si chiede conferma che il requisito possa essere soddisfatto, da una soluzione che assicuri la continuità di servizio e la disponibilità del dato mediante l'insieme dei seguenti meccanismi:
1. ridondanza a livello di controller del percorso dati/storage, realizzata mediante protezione RAID enterprise con ricostruzione automatica online, in coerenza con la finalità di continuità di servizio esplicitata dal medesimo §4.3;
2. alimentatori ridondanti hot-swap (N+1) con failover automatico e trasparente;
3. ventole ridondate;
4. dischi hot-swap con protezione RAID enterprise e ricostruzione automatica online;
5. porte di rete multiple ridondanti con bonding e failover automatico;
6. Architettura e meccanismi di integrità del dato self-healing e continuità, con verifica e correzione automatica degli errori a livello di filesystem e di storage controller, che garantisce la disponibilità e la consistenza dei dati di backup anche in presenza di guasti hardware puntuali;
7. monitoraggio proattivo e alerting in tempo reale sullo stato dei componenti.
Si chiede pertanto di confermare che una soluzione avente le caratteristiche sopra elencate — ferma restando la piena soddisfazione di tutti gli altri requisiti del Capitolato — sia conforme al soddisfacimento del requisito di cui al §4.3.

Quesito B.
Con riferimento al requisito minimo obbligatorio indicato al §4.3 del Capitolato Tecnico del Lotto 2, che prevede: "architettura scalabile e modulare, predisposta per l'espansione futura sia in termini di capacità, sia in termini di prestazioni e di tecnologia adottata, senza interruzione del servizio" si chiede conferma che il requisito di espansione in termini di prestazioni, si intenda soddisfatto da una soluzione che, pur non prevedendo l'aggiunta di componenti computazionali a caldo sull'appliance, sia dimensionata e presenti congiuntamente sin dalla configurazione iniziale le seguenti caratteristiche:
1. capacità espandibile in modo modulare mediante aggiunta di shelf di storage a caldo, senza interruzione del servizio;
2. prestazioni di ingest e deduplicazione garantite per l'intera durata contrattuale (5 anni) da un dimensionamento iniziale del controller tale da coprire con adeguato margine l'intero workload di produzione dichiarato in Tabella 1 (§3.2), comprensivo delle proiezioni di crescita ivi indicate (5% giornaliero, 5% annuale), in assenza di dati criptati o non deduplicabili, anche in assenza di aggiunta a caldo di componenti computazionali sull'appliance;
Si chiede pertanto di confermare che una soluzione avente le caratteristiche sopra descritte sia rispondente al requisito di cui al §4.3.

Quesito C.
Con riferimento al paragrafo 4.2 ed al paragrafo 4.5, tra gli obiettivi operativi che la soluzione dovrà soddisfare, il seguente requisito: "offrire resilienza cyber e continuità operativa tramite replica remota, verifica costante dell'integrità dei backup e delle procedure di ripristino in ambienti isolati di test". In tal senso, si chiede conferma alla SA che tale requisito minimo debba intendersi soddisfatto esclusivamente come: obbligo di proporre una soluzione predisposta a livello architetturale / infrastrutturale per l'evoluzione verso funzionalità di resilienza cyber e continuità operativa mediante replica remota; Confermando di fatto che la fornitura oggetto dell’appalto non comprendere anche l'infrastruttura hardware del sito secondario necessaria all'effettiva implementazione della replica.

Quesito D.
Il § 4.5 del Capitolato Tecnico con riferimento al requisito di integrazione nativa con piattaforme NDR (Network Detection and Response) per l'acquisizione e la correlazione automatica degli Indicatori di Compromissione (IOC), si chiede di precisare se la Stazione Appaltante disponga già di una piattaforma NDR e, in caso affermativo, di indicarne il produttore, al fine di consentire la corretta valutazione della compatibilità e dell'integrazione della soluzione proposta.

Quesito E.
Il § 4.8 del Capitolato Tecnico, con riferimento al requisito migliorativo "Replica e DR", si chiede CONFERMA CHE le funzionalità di failover/failback siano da intendersi quali capacità della soluzione di effettuare il ripristino dei dati dal sito secondario in caso di indisponibilità del sito primario.

Quesito F.
Il § 5 del Capitolato Tecnico definisce il servizio di manutenzione come «servizio di tipo 'full service on site' e Next Business Day 8x5 (copertura per 8 ore al giorno, 5 giorni a settimana, orario lavorativo d'ufficio, 09:00 - 17:00, dal lunedì al venerdì)» e prevede altresì «la presa in carico del malfunzionamento entro un tempo massimo di 4 ore dalla segnalazione».
Si chiede conferma che il termine di 4 ore per la presa in carico del malfunzionamento debba intendersi nel rispetto e in coerenza con il livello di servizio NBD 8x5 contrattualizzato — ovvero calcolato esclusivamente nell'ambito dell'orario lavorativo (09:00 - 17:00, dal lunedì al venerdì) e non come termine assoluto decorrente anche al di fuori della finestra di copertura contrattuale.

Con riferimento al Lotto 2, siamo a richiedere alcuni chiarimenti tecnici al fine di verificare la piena rispondenza della soluzione di backup e disaster recovery che intendiamo proporre per il progetto Juno+.
La soluzione proposta consente il ripristino e il riavvio immediato delle macchine virtuali, sulla base di specifiche caratteristiche della piattaforma. A tal fine, chiediamo cortesemente di fornire i seguenti chiarimenti:
1. Se le 80 virtual machine siano virtualizzate su VMWARE o altro hypervisor;
2. Cosa si intende per Server Linux Fisici, se effettivamente sono 60 macchine separate con linux installato bare metal o se siano virtualizzati in qualche modo;
3. Sul SIEM: dove è installato? è virtualizzato? e nel caso su che piattaforma?
4. Oltre alla dimensione dello storage (100tb) potete fornirci anche il totale di vCPU e di RAM impegnato? Anche per i server linux fisici.

LOTTO 1

1. Capitolato tecnico 5.2 - Multi-protocol support (NFS, SMB, S3, NVMe-oF, iSCSI) via IPv4 and IPv6
Con riferimento al requisito relativo al supporto multi-protocollo (NFS, SMB, S3, NVMe-oF, iSCSI) tramite protocolli IPv4 e IPv6, si chiede di chiarire se sia ammessa una soluzione composta da più componenti storage appartenenti alla medesima piattaforma tecnologica del produttore proposto, nella quale il supporto di uno specifico protocollo (es. iSCSI) possa essere erogato tramite un cluster storage dedicato e integrato, senza l'utilizzo di sistemi gateway o apparati esterni di conversione protocollo.

2. Capitolato tecnico 5.2 - Multi-protocol support (NFS, SMB, S3, NVMe-oF, iSCSI) via IPv4 and IPv6
Si richiede se lo storage in offerta debba supportare la possibilità di fornire iSCSI, con cluster dedicato in futuro.

3. Capitolato tecnico 5.2 - "Funzioni avanzate di data reduction, inclusa compressione e deduplica”
Con riferimento al requisito relativo alle funzionalità avanzate di data reduction, comprendenti compressione e deduplicazione operanti in modalità inline e trasparente all'utente, si chiede di chiarire se possa essere considerata conforme una soluzione che implementi un algoritmo proprietario di ottimizzazione e riduzione dei dati, in grado di garantire la riduzione dello spazio occupato mediante tecniche avanzate di compressione (incluse modalità di compressione basate sullo scenario/workload), operate in modalità inline e senza impatti significativi sulle prestazioni complessive del sistema.

4. Capitolato tecnico 5.2 - "Funzioni avanzate di data reduction, inclusa compressione e deduplica"
Si chiede di confermare che la funzionalità di deduplicazione può essere intesa come requisito non vincolante realizzata con tecnologie alternative di data reduction che garantiscono risultati equivalenti in termini di efficienza dello spazio e trasparenza operativa.

5. Capitolato tecnico 5.2 - "funzioni avanzate di gestione dei dati come snapshot istantanei clonazione dei volumi thin provisioning"
Con riferimento al requisito relativo alle funzionalità avanzate di data management, quali instant snapshot, volume cloning e thin provisioning, si chiede di chiarire se, considerando l'ambito applicativo HPC e la natura delle soluzioni storage scale-out NAS oggetto della fornitura, sia necessario che la piattaforma proposta implementi nativamente funzionalità di volume cloning e thin provisioning a livello block storage.Si evidenzia a tal riguardo che tali funzionalità risultano tipicamente riferite a sistemi storage a blocchi (LUN/volumi), mentre nell'ambito di architetture scale-out NAS per ambienti HPC analoghe funzionalità possono essere implementate a livello filesystem, tramite meccanismi quali snapshot, filesystem clone, Redirect-on-write, quota/provisioning logico o tecnologie equivalenti.

6. Capitolato tecnico 5.2 - "funzioni avanzate di gestione dei dati come snapshot istantanei clonazione dei volumi thin provisioning"
Si chiede di confermare che sono ritenute conformi soluzioni che forniscono funzionalità equivalenti a livello file system/distributed namespace, garantendo gli stessi obiettivi funzionali richiesti, anche qualora non siano presenti oggetti di tipo "volume" in senso block storage.

7. Capitolato tecnico 5.2 - API RESTful documentate per integrazione con infrastrutture moderne ed orchestratori
Con riferimento al requisito relativo alla disponibilità di API RESTful documentate e al supporto nativo di driver Container Storage Interface (CSI) per l'integrazione con ambienti containerizzati quali Kubernetes ed equivalenti, si chiede di confermare che sono ritenute conformi implementazioni CSI dedicate a piattaforme storage scale-out NAS/file. Si evidenzia infatti che, nell'ambito di architetture HPC e AI basate su storage distribuito scale-out NAS, l'integrazione con ambienti containerizzati può avvenire tramite CSI driver file-based (ad esempio NFS/SMB CSI) o tramite operator e integrazioni native equivalenti, garantendo le medesime funzionalità di provisioning, gestione del ciclo di vita dello storage e orchestrazione automatizzata dei workload containerizzati.

8. Capitolato tecnico 5.5 - "Sicurezza e continuità operativa"
Con riferimento al requisito relativo alla cifratura dei dati scritti su supporto fisico, si chiede di chiarire cosa si intende per "senza impatto sulle performance o data reduction".

9. Capitolato tecnico 5.5 - "Sicurezza e continuità operativa"
In particolare, si chiede di confermare che le funzionalità di data encryption e data reduction debbano essere intese come la capacità della piattaforma di supportare entrambe le funzionalità, garantendo che l'abilitazione della cifratura non introduca impatti significativi sulle prestazioni complessive né comprometta le funzionalità di riduzione dati eventualmente configurate.

10. Capitolato tecnico 5.11 - "Il sistema deve poter memorizzare le metriche in un Database integrato in formato tabellare colonnare compatibile con framework Big Data (Spark, Trino, Dremio)"
Con riferimento al requisito relativo alla capacità del sistema di memorizzare metriche mediante un database integrato in formato tabellare colonnare, compatibile con framework Big Data quali Spark, Trino, Dremio ed equivalenti, si chiede di confermare l'equivalenza di soluzioni architetturali integrate composte dalla piattaforma storage e da componenti software dedicate alla gestione dei dati analitici.

11. Capitolato tecnico 5.11 - "Il sistema deve poter memorizzare le metriche in un Database integrato in formato tabellare colonnare compatibile con framework Big Data (Spark, Trino, Dremio)"
Si chiede di confermare che possano essere considerate conformi soluzioni che, attraverso componenti software integrate nella soluzione proposta facenti parte della fornitura, consentano la memorizzazione e gestione dei dati in formato tabellare colonnare (ad esempio mediante formati open table come Apache Iceberg/Parquet o equivalenti) e garantiscano l'accesso e l'elaborazione tramite framework Big Data quali Spark, Trino, Dremio ed equivalenti.

12. Capitolato tecnico 5.11 - "Il sistema deve poter memorizzare le metriche in un Database integrato in formato tabellare colonnare compatibile con framework Big Data (Spark, Trino, Dremio)"
Si chiede di confermare che il requisito debba essere interpretato come capacità complessiva della soluzione proposta di fornire un ambiente integrato per workload Big Data.

13. Capitolato tecnico 5.12 - "Metadata Catalog"
Con riferimento al requisito relativo alla funzionalità di "Metadata Catalog", che prevede la possibilità di indicizzare e catalogare i metadata del filesystem in formato tabellare per consentire ricerche avanzate, attività di reporting e integrazione con workflow di analisi, si chiede di confermare che tale funzionalità sia fornita attraverso soluzioni integrate composte dalla piattaforma storage e da componenti software dedicate alla gestione e indicizzazione dei metadata.

14. Capitolato tecnico 5.12 - "Metadata Catalog"
Si chiede di confermare l'equivalenza di soluzioni che, tramite componenti software integrate nella soluzione proposta facenti parte della fornitura, consentono l'estrazione, indicizzazione e rappresentazione tabellare dei metadata del filesystem, garantendo funzionalità equivalenti di ricerca avanzata, reporting e integrazione con framework di analisi dati.

15. Capitolato tecnico 5.12 - "Metadata Catalog”
Si chiede di confermare che il requisito relativo alla funzionalità Metadata catalog sia riferito esclusivamente ai metadata generati internamente dal sistema storage oppure anche ai metadata dei dati utente memorizzati sulla piattaforma.

16. Capitolato tecnico 5.12 - "Metadata Catalog”
Si chiede di confermare che il requisito relativo alla funzionalità Metadata catalog sia riferito anche ai metadata dei dati utente memorizzati sulla piattaforma.

17. Capitolato tecnico 5.12 - "Integrated Vector Database"
Con riferimento al requisito relativo alla presenza di un "Integrated Vector Database", che prevede un motore database ad architettura colonnare nativamente integrato nella piattaforma storage e funzionalità di Vector Database per la gestione e ricerca per similarità degli embedding generati da modelli di Machine Learning, si chiede di confermare l'equivalenza di soluzioni integrate composte dalla piattaforma storage e da componenti software specialistiche dedicate alla gestione dei dati analitici e vettoriali.

18. Capitolato tecnico 5.12 - "Integrated Vector Database”
Si chiede di confermare sull'equivalenza di architetture nelle quali la piattaforma storage fornisce il livello persistente dei dati non strutturati e le funzionalità di indicizzazione, catalogazione, query analitiche e vector similarity search siano erogate tramite componenti software integrate nella soluzione complessiva proposta.

19. Capitolato tecnico 5.12 - "Integrated Vector Database”
Si chiede di confermare che il requisito "without the use of external databases or ETL processes" possa essere inteso come requisito relativo alla disponibilità di un'integrazione nativa e automatizzata tra storage e servizi analitici.

20. Capitolato tecnico 5.12 - "External Sync Engine”
Con riferimento al requisito relativo alla disponibilità di un "External Sync Engine" integrato nella soluzione proposta, in grado di automatizzare la discovery, catalogazione e migrazione di dati non strutturati provenienti da sorgenti eterogenee (quali S3, file system e servizi SaaS), fornendo inoltre funzionalità di ricerca granulare sui metadata senza l'utilizzo di middleware esterno, si chiede di confermare che tale funzionalità sia realizzabile attraverso soluzioni integrate costituite dalla piattaforma storage e da componenti software dedicate alla gestione del ciclo di vita dei dati.

21. Capitolato tecnico 5.12 - "External Sync Engine”
Si chiede di confermare l'equivalenza di soluzioni che prevedano un servizio di data discovery, metadata cataloging e data migration integrato nella soluzione complessiva proposta, anche qualora tali funzionalità siano erogate tramite componenti software specialistiche interoperabili con la piattaforma storage.

22. Capitolato tecnico 5.12 - "External Sync Engine”
Si chiede di confermare che il requisito relativo all'assenza di middleware esterno possa essere interpretato come capacità della soluzione complessiva fornita di operare senza dipendenze da prodotti non inclusi nella fornitura.

23. Disciplinare 6.3 lotto 1 - Capacità tecnica e professionale
Si chiede di specificare il numero massimo di contratti utili a dimostrare il possesso della capacità tecnica e professionale richiesta considerato che testualmente “il requisito potrà essere dimostrato anche tramite contratti in corso di esecuzione al momento della pubblicazione del bando".

24. Disciplinare 6.3 lotto 1 - Capacità tecnica e professionale
Si chiede di confermare che un singolo contratto relativo alla fornitura di un sistema all-flash superiore a 5PB di importo complessivo superiore a € 5.000.000,00 comprensivo di manutenzione pluriennale fatturata annualmente ed in corso di esecuzione possa essere considerato valido ai fini della dimostrazione del possesso del requisito di capacità tecnica e professionale.