Rapport explicatif

Une nouvelle let. e est ajoutée pour organiser plus efficacement notamment les demandes de codes PUK: il faut aujourd'hui deux demandes IR_4_NA et IR_6_NA, mais à l'avenir une seule demande de type IR_6_NA suffira pour obtenir le code PUK.

Une nouvelle let. f est ajoutée pour permettre les demandes à partir des codes qui sont usuellement utilisés dans les offres à prépaiement pour recharger du crédit ou pour payer la prestation. Il s'agit de ces codes que l'on peut acheter par exemple dans un kiosque ou à la caisse d'un supermarché, sous forme de carte à gratter ou de ticket de caisse. La saisie du code crédite le montant en question sur le compte à prépaiement. La norme ETSI n'avait jusqu'à présent pas encore de champ de données permettant d'utiliser ce genre de code comme critère pour une demande de renseignements. Comme cette possibilité existait déjà avec l'ancienne LSCPT du 31 octobre 2001, le Service SCPT a présenté une requête de changement à l'ETSI, qui l'a entretemps acceptée et intégrée dans la norme. La disposition de l'art. 36 peut donc être complétée en ce sens.

Art. 37, al. 1, phrase introductive (ne concerne que l'allemand) et let. b

Dans la phrase introductive de l'al. 1, une adaptation rédactionnelle est faite dans le texte allemand pour répondre aux règles de la formulation non sexiste.

Le caractère univoque de l'identifiant du service (par ex. nom d'utilisateur) à la let. b se réfère au fournisseur. L'autorité qui souhaite obtenir des renseignements peut utiliser cet identifiant comme critère de recherche pour de nouvelles demandes. L'identifiant du service devra dans la mesure du possible être pourvu d'une désignation appropriée si sa signification ne se comprend pas immédiatement.

Dans les exemples cités à la let. b, l'identifiant DSL est remplacé par le GPSI, un identifiant du système 5G (voir le commentaire de l'art. 35, al. 1, let. d, ch. 2).

Art. 38 Type de renseignements IR_8_IP (NAT): identification des utilisateurs dans le cas d'adresses IP qui ne sont pas attribuées de manière univoque (traduction d'adresses de réseau)

La pratique a montré que les demandes d'identification d'usagers sur la base des adresses IP et d'autres critères n'aboutissent pas toujours à des résultats clairs dans les cas où il y a une traduction d'adresse réseau de classe transporteur, en anglais carriergrade NAT (cgNAT). Cette absence de résultats clairs tient au fait qu'avec une cgNAT, le fournisseur d'accès (le carrier) fait de la traduction d'adresses de réseau (NAT) pour tous ses clients ou pour une grande partie de ceux-ci. Plusieurs clients peuvent dès lors apparaître sur internet simultanément avec la même adresse IP publique, voire aussi avec le même numéro de port (critères obligatoires pour une demande). Comme pour les autres types de recherches, il doit donc être possible d'admettre plusieurs résultats. La possibilité d'obtenir des résultats ambigus lorsque des procédures de traduction d'adresses de réseau entrent en jeu a déjà été signalée dans le rapport explicatif de l'actuelle OSCPT (p. 42).

Pour tenir compte de cette réalité, des adaptations rédactionnelles sont faites à l'al. 1 et dans ses let. a et b, où les termes usagers, identifiants des usagers, identifiants du