Le processus de distribution de NSP est basé sur les exigences du client et les meilleures pratiques suivies par nos autres équipes. L’objectif principal de ce processus est de créer et de gérer des cycles de publication bien définis et prévisibles. Ce processus nous permet de répondre à divers besoins du client. Certains clients doivent rester sur une seule version pendant une période prolongée, plutôt que d’adopter les dernières fonctionnalités de sécurité.

NSP prend en charge les types de distribution suivants :

• Version principale :
  Une version principale, également connue sous le nom de version de référence, est adaptée aux clients qui sont soumis à un contrôle strict des modifications. Une version principale fournit de nouvelles fonctionnalités et améliorations, et est certifiée. Les clients peuvent rester sur cette version pendant une période prolongée.
  
• Version de la fonctionnalité :
  Une version de fonctionnalité fournit de nouvelles fonctionnalités et améliorations. Elle est adaptée aux clients désireux de participer à l’adoption anticipée de nouvelles fonctionnalités.
  
• Version de maintenance :
  Une version de maintenance, également connue sous le nom de version de mise à jour, fournit des correctifs logiciels. Il est fourni tous les deux mois pour les versions principales et les versions des fonctionnalités.
  
• Version de HotFix :
  Une version de HotFix fournit des correctifs logiciels pour les versions principales et les versions des fonctionnalités. Elle est uniquement nécessaire pour sélectionner les clients qui demandent des correctifs immédiats et qui ne peuvent pas attendre la version de maintenance. Un Hotfix peut également inclure plus d’un correctif.

Remarque : NSP Engineering détermine au moment de la publication de la version si une version est une fonctionnalité ou une version principale. Le numéro de version de la version est sélectionné en conséquence.

Vous trouverez ci-dessous un exemple de cadence de libération pour les versions du logiciel NSP :


Remarque les termes suivants, qui expliquent la stratégie de support logiciel pour NSP, sont utilisés dans ce document :

• Période de fin de vie (EoLP) :
  EoLP est le laps de temps à partir du jour où nous anannoncent la sortie de la version du produit jusqu’au dernier jour où la version du produit est formellement prise en charge. EoLP est la période comprise entre le début de la fin de vie (EoLS) et la fin de vie (EoLE).
• EoLS : les deux scénarios suivants sont applicables :
  • Une fois EoLS déclaré, aucune autre version de maintenance n’est disponible au cours de l’EoLP. La prise en charge des jeux de signature complets et les HotFix sont fournis au cours des 12 prochains mois.
  • Pour les distributions principales, il existe un support étendu d’un an sur 12 mois (un total de 24 mois après EoLS).
    Au cours de cette période, aucune autre distribution de maintenance n’est effectuée. La prise en charge des jeux de signature complets et des HotFix critiques limités est fournie.
• EoLE : aucun jeu de signature ou Hotfix n’est fourni. Le logiciel est en fin de vie.
  Vous trouverez ci-dessous une illustration d’une version principale et du cycle de vie des fonctionnalités :

La liste ci-dessous répertorie les caractéristiques d’une version principale par rapport à une version de fonctionnalité :

	Distribution principale	Version de la fonctionnalité
Version	Le deuxième chiffre de la version du produit est numéroté ". 1". Par exemple 9.110.1 ,, 11.1.	Le deuxième chiffre de la version du produit est numéroté. 2,. 3, etc. Par exemple 9.29.310.2 ,,, 10.3.
Étendue de la version	Une version principale peut inclure des améliorations logicielles pour les éléments suivants : Nouvelles fonctionnalités Mise à jour de l’infrastructure Prise en charge Présentation du nouveau matériel Certification	Une version de fonctionnalité peut inclure des améliorations logicielles pour les éléments suivants : Nouvelles fonctionnalités Mise à jour de l’infrastructure Prise en charge Présentation du nouveau matériel
Chronologie	La distribution principale est d’environ dix-huit mois.	La version de la fonctionnalité est à environ tous les 6 mois jusqu’à la prochaine distribution principale.
Période de support	La période de prise en charge des versions principales est de 48 mois : 24 mois d’ingénierie et de Support technique-Mme, Hotfix et prise en charge de jeux signature complets 24 mois de Support technique 24 à 36 mois-non-Mlle, Full signature Set support et Hotfix 37 à 48 mois-pas de Mme, Full signature Set support et des HotFix critiques limités	La période de prise en charge des versions de fonctionnalités est de 20 mois : 8 mois d’ingénierie et de Support technique-Mme, Hotfix et prise en charge de la définition complète signature 12 mois d’Support technique-pas de Mlle, Full signature Set support et Hotfix
EoLS	EoLS est 24 mois après GA. Une annonce de fin de vie est envoyée pour indiquer cette phase.	EoLS est de 8 mois après GA. Une annonce de fin de vie est envoyée pour indiquer cette phase.
EoLP	EoLP est de 24 mois.	EoLP est de 12 mois.
EoLE	EoLE est 24 mois après EoLS.	EoLE est 12 mois après EoLS.
Version de maintenance	La mise à jour de la maintenance est prévue pour être fournie tous les deux mois, sur la base de EoLS.	La mise à jour de la maintenance est prévue pour être fournie tous les deux mois, sur la base de EoLS.
HotFix	Les HotFix sont fournis en fonction des besoins à l’aide des deux scénarios suivants : Une fois EoLS déclaré, des HotFix sont fournis au cours des 12 prochains mois. Pour la période restante jusqu’à EoLE, des HotFix critiques limités sont fournis.	Les HotFix sont fournis en fonction des besoins, jusqu’à EoLE.
Jeu de signatures	Les mises à jour des jeux de signatures sont fournies jusqu’à EoLE.	Les mises à jour des jeux de signatures sont fournies jusqu’à EoLE.
Correction des vulnérabilités	Les correctifs de vulnérabilité sont fournis en fonction de vos besoins, jusqu’à EoLE.	Les correctifs de vulnérabilité sont fournis en fonction de vos besoins, jusqu’à EoLE. Important : NSP Engineering peut autoriser un exception dans certains cas où un effort important est nécessaire pour prendre en charge le correctif. L’approbation de l’en-tête Business est nécessaire pour les exceptions.
Prise en charge du nouveau matériel/plate-forme	Toute nouvelle plate-forme ou tout nouveau matériel NSP est pris en charge dans les versions principales de la version ou des fonctionnalités, en fonction de la portée des modifications impliquées.
Certification	Chaque version principale est certifiée pour le APL CC/FIPS/Cu, etc. Les versions de certification sont numérotées sous la forme 9.1.15.x , 9.1.17.x , 9.1.19.x.
Localisation	La localisation de l’interface utilisateur du module Manager rapports et de la documentation produit est disponible pour la version principale, et est disponible par MR1 de la distribution principale. L’interface utilisateur et la documentation de chaque version de la fonction Release Manager sont localisées. L’interface utilisateur des rapports de Manager et la documentation produit globale sont localisées dans les langues suivantes : japonais, coréen, simplifié et chinois traditionnel.

Questions fréquemment posées :

je suis un client NSP existant. Quand est-il possible d’attendre la mise en œuvre de la version actuelle du processus de distribution de NSP ?
Le processus de distribution de NSP décrit dans ce document est applicable au 4e trimestre, 2017.

Je suis un nouveau client et je souhaite installer NSP. Quelle branche de distribution dois-je utiliser ?
Il est conseillé d’installer une version de fonctionnalité pour bénéficier des dernières fonctionnalités et améliorations. Toutefois, votre décision doit tenir compte du processus change Control de votre organisation. Si votre organisation applique une stratégie de mise à niveau stricte ou si elle souhaite rester sur une version unique pendant une période prolongée, il est conseillé d’utiliser la version principale.

J’utilise la version 9.1. principale puis-je passer à la version 9.2 de fonctionnalité ?
Oui. Toutefois, une fois qu’une version de fonctionnalité est adoptée, vous devez rester sur le chemin d’accès de la fonctionnalité jusqu’à ce que la version principale suivante soit mise à disposition.
Si vous devez revenir à la version précédente, vous devez reconfigurer et recommencer.

Quelles sont les options de mise à niveau prises en charge entre les versions principales et les versions de fonctionnalités ?
Les scénarios de mise à niveau pris en charge pour les logiciels Sensor et Manager sont les suivants :

• Les mises à niveau de la version principale précédente vers la version principale suivante sont prises en charge. Par exemple, de 8.1 a à 9.19.110.1.
• Les mises à niveau de la fonctionnalité précédente vers la version suivante sont prises en charge. Par exemple, s’il existe des versions 9.2 de fonctionnalités et 9.3 que vous êtes actuellement actif 9.2 , vous pouvez effectuer une mise à niveau vers 9.3.
• Les mises à niveau à partir des versions précédentes des deux fonctionnalités vers la version principale suivante sont prises en charge. Par exemple, s’il existe des versions 8.28.3 , vous pouvez effectuer une mise à niveau de 8.2 et 8.3 des deux vers 9.1.

Les versions de la Manager prennent-elles en charge les capteurs hétérogènes de fonctionnalités et de versions principales ?
Les scénarios pris en charge sont les suivants :

• La version principale de Manager prend en charge les capteurs hétérogènes pour la version principale immédiatement précédente et la version précédente immédiate de la fonctionnalité. Par exemple : le 9.1 Manager prend en charge les capteurs qui s’exécutent sur 9.1 , 8.1 et la dernière version de la fonctionnalité dans le 8.x logiciel Sensor.
• La version Manager de la fonctionnalité prend en charge les capteurs hétérogènes pour la libération immédiate de la fonctionnalité précédente et la version précédente immédiate précédente. Par exemple : le Manager prend en charge les capteurs exécutés 8.3 et 8.1 les 8.3 logiciels Sensor.

Remarque : Le troisième chiffre varie en fonction des différents modèles de Sensor. Par exemple, M-Series is 8.1.3.x et NS-Series sont 8.1.5.x.

Les versions de la Central Manager prennent-elles en charge les gestionnaires hétérogènes de fonctionnalités et de versions principales ?
Les scénarios pris en charge sont les suivants :

• La Central Manager principale prend en charge les gestionnaires hétérogènes pour la version précédente Manager immédiate et la version précédente Manager. Par exemple : le 9.1 central Manager prend en charge les gestionnaires exécutant 9.1 , 8.1 et la dernière version de la fonctionnalité dans le 8.x logiciel Manager.
  
• La fonctionnalité Central Manager version prend en charge les gestionnaires hétérogènes pour la libération immédiate de la fonctionnalité précédente et la version précédente immédiatement précédente. Par exemple : le Central Manager prend en charge les gestionnaires exécutés 8.3 et 8.1 les 8.3 logiciels Manager.

Fournissez-vous un notification d’avance lorsque les clients conseillent de mettre à niveau le logiciel Sensor vers une version minimale recommandée pour des raisons critiques ?
Lors de l’annonce d’une nouvelle Sensor image logicielle pour résoudre tout problème ou vulnérabilité critique, nous fournissons les éléments suivants :

• Une fenêtre de six mois qui permet aux clients de procéder à la mise à niveau vers l’image minimale recommandée s’il existe une version de la fonctionnalité (par exemple, 8.28.3 de a) ou une version de maintenance (par exemple, de 8.3.5.158.3.5.30 a).
• Une fenêtre de 12 mois qui permet aux clients de procéder à la mise à niveau vers l’image minimale recommandée s’il existe une version principale (par exemple, de 9.110.1 a).