Ma lecture du brouillon des lignes directrices relatives à l'application de la neutralité des réseaux concocté par le régulateur européen des télécoms + ma réponse à la consultation publique organisée par le même régulateur du 6 juin au 18 juillet 2016.
Paragraphe 8 et suivants : seuls sont soumis au règlement européen les fournisseurs de communications électroniques au public qui englobent réseaux de communication publics + services de communication électroniques publics.
Paragraphe 16 : même si un accès Internet se définit comme l'accès à toutes les extrémités de ce réseau (sauf contraintes techniques ou légales) ne peut pas être vu comme une obligation de fournir une connectivité IPv6 et IPv4. Bien vu, les grozopérateurs… Pourtant IPv6 est nécessaire au maintien d'un Internet ouvert. Exemple : quand le RIPE et les LIR seront à sec et que l'on n'a pas migré : comment je monte un FAI associatif ? 99,99 % des LIR veulent que le FAI monte une interconnexion avec lui au nom du principe "je dois pouvoir router tout mon réseau". Or, les interconnexions coûtent cher, surtout si le LIR est à Paris et que tu montes un FAI en province. Ça sera une structure d'exclusion. De même si je veux monter un service : je devrais le faire chez un gros hébergeur qui aura encore des IPv4. Concentration des acteurs.
Pour moi, c'est incomplet :
Sur les offres FTTH, pour juste avoir accès à Internet, il faut que le routeur de remplacement envoie un vendor-id (attribut dans la requête DHCP, voir https://www.neufbox4.org/wiki/index.php?title=Bypasser_sa_neufbox#Le_.22Vendor_class_identifier.22 ) soit générique soit spécifique à un réseau (RIP) ou localité donnée ! Qui peut se permettre un tcpdump de sa connexion pour le trouver ?! Le choix du terminal n'est pas garanti !
Je n'ai pas de vraies idées pour corriger ça.
Considérant 7 : d'éventuels contrats entre FAI et clients sur des tarifs pour des débits et des volumes différenciés, des caractéristiques techniques ou toute pratique commerciale ne doivent pas restreindre les droits des clients (ceux du cadre général, article 3(1). C'est le cadre général du Règlement.
Le principe général n'empêche pas les FAI de prendre des mesures de gestion du trafic raisonnables mais elles doivent être transparentes, non discriminantes, proportionnées, et basées exclusivement sur un besoin différencié d'une qualité de service de la part d'une catégorie de trafic. Ces mesures ne peuvent regarder le contenu (au-delà de la couche de transport, ni discriminer le trafic chiffré, paragraphes 66 et 67) ni être maintenues plus longtemps que nécessaire.
Considérant 11 : la compression de données sans modification du contenu est autorisée parce qu'elle participe à l'optimisation globale du réseau et que ça rend service à l'utilisateur.
J'y suis opposé : ça signifie que le FAI possède des proxy transparents par lesquels transite mon trafic web non chiffré ! Ces machines ont les URL dans leurs journaux. On interdit aux FAI d'aller plus haut que la couche transport pour leurs mesures de gestion du trafic dans les paragraphes 66 et 67 et dans le CPCE mais là, lala ?! Ce n'est pas au FAI de décider mais aux extrémités du réseau : le site web auquel j'accède propose gzip, mon navigateur accepte. De même que La Poste ne réorganise pas mes colis. Au moins, la compression et mise en cache de SFR ( voir https://reflets.info/sfr-man-in-the-middle-oui-cest-particulierement-grave/ ) ne passera pas car elle altère le contenu, c'est déjà ça mais c'est peu.
Paragraphe 75 : « In contrast to network-internal blocking put in place by the ISP, terminal equipment-based restrictions put in place by the end-user are not targeted by the Regulation. ».
Des mesures de gestion du trafic déraisonnables (qui dépassent le cadre général, quoi) peuvent être prises pour :
Préserver l'intégrité et la sécurité du réseau, du service fourni ou celle du terminal utilisateur.
Mitiger une congestion imminente, exceptionnelle (pas prévisible, pas souvent) ou temporaire (répétée mais limité dans le temps (ex: mobile) ou qui ne justifie pas un investissement d'augmentation de la capacité réseau).
Les régulateurs doivent surveiller si les opérateurs dimensionnent correctement leur réseau. Une congestion récurrente et de long terme ne peut être couverte par cette exception (paragraphe 89). Une gestion de congestion qui vise une appli ne devrait pas être acceptée comme substitue pour des changements structurels du réseau. \o/
Cas concrets : selon ces lignes directrices,
Hello,
I'm participating to this consultation on Net Neutrality guidelines as a French citizen considering exercising his liberties (freedom of expression, freedom of information, ...) requires an open Internet. My contribution is realised on my spare time. My professional job is as a software developer but I never worked for an ISP or a CAP.
Firstly, I deplore this consultation is only in English (guidelines are only available in English, "Contributions should be sent preferably in English", ...) because it prevents some small actors like citizen and small ISPs from participating: reading legal documents in English isn't mandatory for setting up a little ISP in a small city in France. Doing this, BEREC tries to restrict participation to those only from historic nationwide ISP lobbyists! This is unacceptable.
Then, I approve and give my full support to paragraphs 17, 59, 60, 65, 66, 67, 74, 86, 88, 89, 97, 101, 107, 108, 113, 114. I strongly encourage you to keep them as-is in the final guidelines.
On paragraph 16An IAS end-user requires IPv6 to "provide applications and services" (article 3(1)). Public IPv4 addresses are exhausted. However, a public IP address is required to provide applications, services, or contents. In France, nationwide ISPs do not provide public IPv4 addresses in their mobile IAS. IPv6 is the only way for ISPs to satisfy to the obligations as stated in article 3(1) of the Regulation for now and in the future.
Moreover, in a few years from now, a new ISP won't be able to enter the market: there won't be any more public IPv4 addresses available to them. It will then provide its end-users with IPv6 access. If the IPv6 contents, services, applications still are in minority as it is the case today, this ISP won't be able to sell IAS as no potential client will be interested in it because he cannot do something with its connection. This technical consideration will be a reason for market exclusion. ISPs and CAPs must deploy IPv6 from now to prevent this.
On the use of the terminal equipment of their choice (paragraphs 23-25)The BEREC analysis is weak and incomplete.
You're wrong in paragraph 51: Endpoint-based congestion control takes place on my computer behind the terminal! On a home IAS, the terminal is the home-router, i.e. the equipment between my private home network and my ISP's network; between my computers, tablets, smartphones, and Internet. On a mobile IAS, the terminal is my smartphone's baseband module. As I can choose my smartphone model, I can choose my terminal. BEREC must clearly state that the home-router is the terminal (called "box" in France: LiveBox, FreeBox, NeufBox) and that the terminal isn't part of the ISP's network because it is part of the end-user's domestic material (like are tables, chairs, TV, ...).
In France, changing the home-router on a FTTH IAS is very hard: the terminal must send a technical information (called "DHCP vendor-id attribute") to the ISP in order to connect to its network and obtain its public IP address. This information is specific to an ISP, or even a geographic area! The information isn't communicated by the ISP to the end-user when signing the contract. Other IAS technical characteristics are also hidden from the end-user (e.g. "VLAN ID"). The freedom the end-user has of choosing his terminal under article 3(1) is then restricted as the end-user must have solid technical knowledge in the matter in order to find out his IAS' technical characteristics if he wishes to replace his terminal. Yes, I'm only talking about IAS specifically, not associated services (telephony, television). NRAs must be vigilant about this;In France, all nationwide ISPs attach services to the IAS, like telephony, television (linear broadcasting or VOD) or videogames in a bundle billed about €30 per month. These bundled services do not directly limit the end-user rights but are more likely to influence end-users’ exercise of the rights defined in Article 3(1) to keep the home-router provided by their ISP in order to benefit from the additional services they pay each month even if they won't actually use them. Consequently:
*NRAs must force ISPs to publish all their IAS and specialised services' technical specifications (e.g. vendor-ID, VLAN-ID, ...). This way, any constructor will be able to sell alternatives to the ISP's home-router still allowing access to both the IAS and the specialised services. Each end-user will then be able to effectively choose his own terminal. This effort on transparency is necessary for a perfect competition.
NRAs must force ISPs to clearly indicate the home router renting costs on the end-user's montly bill. This way, end-users will be aware of the effective costs of this rent and will be able to make an informed decision to buy a home-router independetly from their ISP. End-users must be free to refuse the ISP's home-router. In this case, end-users cannot be billed by the ISP for renting the router.
- NRAs must force ISPs to propose IASes alone, without any specialised services. Such offers must be less costly than the offers bundling services (Internet + telephony + TV + …). They must be easily recognisable in the ISP's catalogue. ISPs are network providers, not services providers (like TV or telephony).
This is a crucial point in the Regulation because several other paragraphs are based on this assertion, like paragraphs 75 et 51. IAS restrictions or congestion control mechanisms applied on the end-user side may only be excluded from the Regulation if the terminal choice is fully under the end-user's control. Otherwise, Regulation and end-user rights violations (e.g. traffic management measures, discriminatory congestion control, restrictions, …) will be observed.
On the zero-rating offers (paragraphs 37 – 45)I strongly second BEREC analysis on paragraph 38.
I strongly disapprove BEREC analysis from paragraph 45 stating that "Commercial practices which apply a higher price to the data associated with a specific application or class of applications are likely to limit the exercise of end-users’ rights because of the potentially strong disincentive" although that a commercial zero-rating practice only "creates an economic incentive to use". It is a strange analysis: applying a zero price to an application or to a category of applications OR applying a higher price to an application or to a category of applications have the same impact on the end-user's choice: who will seriously continue paying the non-zero-rated application?!
The zero-rating practice inherently limits end-users right, notably their right to "provide applications and services" (article 3(1)): my own service or application stays invisible and has no audience as the market is tricked as customers have to pay to access my service or application while access to concurrent services or applications is free! This highly discourages innovation on the Internet.
Each NRA will have to evaluate and potentially sanction each ISP's own practice. It is a loss of time and resources for NRAs. Even if a practice gets sanctioned, it will have created an habit on the public to use a specific service or application. A public that might not have adopted it if it wasn't for the zero-rating offer. A zero-rating offer from an ISP may durably create a strong distortion on services and applications markets.
For those reasons, BEREC must prohibit zero-rating offers on the ground they inherently limit end-users from exercising their rights, which infringes article 3(2).
On the traffic management measures (paragraphs 46-89)Paragraph 51: NRAs must make sure no traffic management measures (like ECN, DiffServ (RFC 2474), ...) are set up by ISPs on home-routers without the end-user knowledge to ensure that ISPs don't circumvent to the Regulation.
BEREC must add an additional guideline: every traffic management measure set up by the ISP, whether reasonable or not, and whether on the network or the end-user terminal, must be under the whole control of the end-user. The end-user must be able to easily (with e.g. a clear and comprehensible option in the ISP-provided home-router) and without any additional cost, disable (or enable) any traffic management measure.
- As an end-user, I must be able to disable prioritisation of VoIP applications or any other traffic category, even if it is offered as a sepcialised service.
- As an end-user, I must be able to disable a technical blockage of an application or service my ISP would have set up, because I "shall have the right to (...) provide applications and services" (article 3(1)). For example, in France, a traffic management measure is set up by many ISP to prevent the end-users' computer from sending emails in order to avoid it sending spams in case it has been infected by a virus. As an end-user, I can decide to disable this traffic management measure in order to propose a legitimate emailing service on my IAS. In France, many nationwide ISPs, like Orange or Darty, prevent me from sending emails from my home IAS, restraining my rights under article 3(1). Some other ISP, like Free or SFR, open the emailing service via an opt-out option. The latter approach is the right one and NRAs must to strongly encourage it.
I second paragraphs 6 and 89: « NRAs may take into account the interconnection policies and practices of ISPs in so far as they have the effect of limiting the exercise end-user rights under Article 3(1). » and « if there is recurrent and more long-lasting network congestion in an ISP's network, the ISP cannot invoke the exception of congestion management ».
But, BEREC needs to clarify paragraph 47: an interconnection of poor quality (capacity, latency, jitter, ...) between two ISPs necessarily create an incentive for the end-users to favour a service or an application (the fastest one) over a technically and functionally equivalent concurrent offer. In such a case, the ISP has restricted the end-user choice, which is an infringement on article 3(1). It is even worse if the privileged service is the ISP's one.
ISPs must provide the same level of quality to virtually all end-points of the Internet. NRAs shall monitor the ISPs interconnection quality and apply sanctions on the ISPs if necessary. In France, the ARCEP works on this matter for a couple of years.
Paragraph 47 probably means that an interconnection between two ISPs isn't an end-user IAS. If yes, this point is OK.
On specialised services (paragraphs 95-123)Paragraph 109: the linear broadcasting IPTV example is biased: some French ISPs provide broadcasting IPTV service and their own VOD service in one single specialised service considering that it all is television after all. Those ISPs then prioritise their own VOD service to the detriment of concurrent VOD services. This is a circumvention of article 3(3) of the Regulation. NRAs must be vigilant on this point.
Paragraph 118: an ISP shall not, in any circumstances, limit the end-user's network capacity. This must always be considered an infringement to the Regulation by NRAs, even if the end-user has been informed (Article 4(1)(c)). If limiting the end user's capacity was acceptable, it would mean the end-user didn't mean to subscribe to an IAS but to the specialised service, so consequently the ISP should not have sold an IAS to the end-user as it is not what he needed. Moreover, in France, specialised services are sold in a commercial bundle (so-called "triple-play" offer) at a charm pricing in an incentive way to prevent the end-user from requesting an IAS without specialised services. These bundled offers aren't easily recognisable in the ISPs' catalogue.
Best regards.
Bonjour,
Je participe à cette consultation sur les lignes directrices relatives à la Neutralité des Réseaux en tant qu'un citoyen français qui considère qu'un Internet ouvert est nécessaire à l'exercice de ses libertés (liberté d'expression, liberté d'information, etc.). Ma contribution est réalisée sur mon temps libre. Mon métier est programmeur informatique mais je n'ai jamais travaillé pour un FAI ou un FSI.
Pour commencer, je déplore que cette consultation se déroule exclusivement en anglais (les lignes directrices sont uniquement publiées en anglais, "Contributions should be sent preferably in English", etc.) car cela nuit à la participation de petits acteurs comme les citoyens ou les petits FAIs : il n'est pas nécessaire de savoir lire des documents légaux pour créer un FAI dans une petite ville de France. Le BEREC essaye de restreindre les participants au cercle des lobbyistes des FAI d'envergure nationale historiques. C'est inacceptable.
Ensuite, j'approuve et je soutiens fortement les paragraphes 17, 59,60,65,66,67, 74, 86,88,89, 97,101,107,108,113,114. Je vous encourage vivement à les conserver dans les lignes directrices finales.
Concernant le paragraphe 16Un utilisateur final d'un IAS a obligatoirement besoin d'IPv6 pour « provide applications and services » (article 3(1)). Il n'y a plus d'adresses IPv4 publiques disponibles. Pourtant, il faut une adresse IP publique pour fournir une application, un service ou un contenu. En France, les FAI d'envergure nationale ne fournissent pas d'adresse IPv4 publique sur leurs accès Internet mobiles. IPv6 est le seul moyen pour les FAI de satisfaire aux obligations de l'article 3(1) du Règlement dès aujourd'hui.
De plus, dans quelques années, un nouveau FAI ne pourra pas entrer sur le marché : il ne pourra pas obtenir d'adresses publiques IPv4. Il fournira donc à ses utilisateurs finaux un accès Internet exclusivement IPv6. Si les contenus, services ou applications IPv6 sont minoritaires comme c'est le cas aujourd'hui, ce FAI ne pourra pas vendre son accès à Internet : aucun client potentiel ne sera intéressé parce qu'il n'aura aucun usage de sa connexion. Cette considération technique sera un motif d'exclusion du marché. Les FAI et les FSI doivent déployer IPv6 dès aujourd'hui pour empêcher cela.
Concernant la liberté de l'utilisateur final d'utiliser le terminal de son choix (paragraphes 23-25)L'analyse du BEREC est faible et incomplète.
Vous vous trompez dans le paragraphe 51 : le contrôle de la congestion est effectué par mon ordinateur situé derrière le terminal. Sur un accès à Internet fixe, le terminal est le routeur domestique, c'est-à-dire l'équipement entre mon réseau domestique privé et le réseau de mon ISP, entre mes ordinateurs, tablettes, smartphones et Internet. Sur un accès à Internet mobile, le terminal est le module baseband de mon smartphone. Comme j'ai le choix de mon smartphone, j'ai le choix du terminal. Le BEREC doit clairement affirmer que le routeur est le terminal et qu'il ne fait pas partie du réseau du FAI.
En France, changer de routeur domestique sur un accès à Internet FTTH est très difficile : une information technique (nommée « attribut DHCP vendor-id ») doit être envoyée par le terminal afin d'être connecté au réseau et d'obtenir son adresse IP publique . Cette information est spécifique à un opérateur voire à une zone géographique ! Cette information n'est pas communiquée par le FAI à l'utilisateur final à la signature du contrat. D'autres caractéristiques techniques du service d'accès à Internet sont également dissimulées à l'utilisateur final (exemple : « VLAN ID »). Donc, la liberté de choix du terminal par l'utilisateur final n'est pas effective puisque celui-ci doit avoir de solides compétences en informatique pour obtenir les caractéristiques techniques de son service d'accès à Internet s'il désire changer de terminal. Je parle bien exclusivement du service d'accès à Internet, pas des services associés (téléphonie, télévision). Les autorités nationales de régulation doivent être très vigilantes sur ce point.
En France, tous les FAI d'envergure nationale associent des services au service d'accès à Internet comme un service de téléphonie ou de télévision (linéaire ou VOD) ou de jeux vidéos dans un forfait mensuel facturé moins de 30 €/mois. Ces services incorporés ne limitent pas directement les droits des utilisateurs prévus à l'article 3(1) mais ils sont de nature à fortement inciter les utilisateurs finaux à conserver le routeur domestique fournit par leur FAI pour profiter des services qu'ils payent tous les mois même s'ils ne les utilisent pas ! En conséquence :
- Les autorités nationales de régulation doivent imposer aux FAIs la publication de toutes les spécifications techniques (exemples : « vendor-id », « VLAN-ID », etc.) de leur service d'accès à Internet et de tous les services associés à celui-ci. Ainsi, n'importe quel fabricant de routeurs pourra vendre des routeurs domestiques alternatifs à ceux des ISP qui permettent de profiter du service à Internet et des services associés. Tout utilisateur final pourra donc choisir le terminal de son choix. Cet effort de transparence est nécessaire à une concurrence pure et parfaite.
- Les autorités nationales de régulation doivent imposer aux FAI d'indiquer, clairement, sur leur facture mensuelle, le prix de la location du routeur domestique. Ainsi, les utilisateurs finaux auront connaissance de la non-gratuité de cette location et pourront décider d'acheter un routeur domestique indépendant de leur FAI. Les utilisateurs finaux doivent être libres de refuser le routeur domestique proposé par le FAI. Dans ce cas, l'utilisateur final ne peut pas être facturé pour cette location par le FAI.
- Les autorités nationales de régulation doivent imposer aux FAI de proposer des offres de service d'accès à Internet nu, sans aucun service ajouté. Ces offres doivent être moins chères que les offres groupées (Internet + téléphone + TV + etc.). Elles doivent être facilement identifiables dans le catalogue du FAI. Un FAI est un fournisseur de réseau, pas un fournisseur de services comme de la télévision ou de la téléphonie.
Ce point est un point central du Règlement car plusieurs points reposent dessus comme les paragraphes 75 et 51. Des restrictions du service d'accès à Internet ou les mécanismes de contrôle de la congestion appliqués côté utilisateur final peuvent être hors champ de la régulation seulement si l'utilisateur a le choix complet de son terminal. Sinon, des violations du Règlement et des droits des utilisateurs finaux (exemples : mesure de gestion du trafic, contrôle de la congestion discriminatoire, restrictions, etc.) seront encore constatées.
Concernant les offres « zero-rating » (paragraphes 37-45)J'appuie fortement l'analyse du BEREC énoncé au paragraphe 38.
Je désapprouve fortement l'analyse du BEREC énoncée dans le paragraphe 45 selon laquelle une « Commercial practices which apply a higher price to the data associated with a specific application or class of applications are likely to limit the exercise of end-users’ rights because of the potentially strong disincentive » alors qu'une pratique commerciale de zero-rating « creates an economic incentive to use ». C'est une analyse étrange : appliquer un prix = 0 pour une application ou une catégorie d'applications OU appliquer un prix plus élevé pour une application ou une catégorie d'applications a le même impact sur la décision de l'utilisateur final : qui continuera sérieusement à payer l'application à laquelle le zero-rating ne s'applique pas ?!
La pratique du zero-rating limite obligatoirement les droits des utilisateurs finaux, notamment leur droit de "provide applications and services" (article 3(1)) : mon service ou application reste invisible et n'a aucune audience parce que le marché est truqué puisqu’il faut payer pour accéder à mon service ou application alors que l'accès aux services et applications des autres acteurs est gratuit ! Cela décourage fortement l'innovation sur Internet.
Chaque pratique de chaque FAI devra être évaluée et éventuellement sanctionnée par l'autorité nationale de régulation de chaque pays membre de l'UE. C'est une perte de temps pour ces autorités. Même si une pratique est sanctionnée, elle aura créé une habitude entre un service ou une application et un public. Un public qui ne l'aurait pas forcément adopté sans l'offre de zero-rating. Une offre de zero-rating proposée par un FAI peut déséquilibrer durablement des marchés de services et d'applications.
Pour ces raisons, le BEREC doit interdire les offres de zero-rating au motif qu'elles limitent obligatoirement l'exercice des droits des utilisateurs, ce qui enfreint l'article 3(2).
Concernant les mesures de gestion du trafic (paragraphes 46-89)Paragraphe 51 : les autorités nationales de régulation doivent veiller à ce que les mesures de gestion du trafic (ECN, DiffServ (RFC 2474), …) ne soient pas configurées par le FAI, à l'insu de l'utilisateur final, sur les routeurs domestiques qu'ils fournissent sinon, le Règlement est contourné.
Le BEREC doit ajouter une ligne directrice supplémentaire : toute mesure de gestion du trafic, raisonnable ou non, mise en place par le FAI, sur son réseau ou sur le terminal de l'utilisateur final, doit être sous le contrôle intégral de l'utilisateur final. L'utilisateur final doit pouvoir désactiver (et activer) facilement (avec une option compréhensible dans l'interface du routeur domestique fourni par le FAI), sans surcoût, toute mesure de gestion du trafic.
- En tant qu'utilisateur final, je dois pouvoir désactiver la priorisation des applications VOIP ou de toute autre catégorie de trafic même si c'est un service spécialisé.
- En tant qu'utilisateur final, je dois pouvoir désactiver le blocage technique d'une application ou d'un service réalisé par mon FAI car "shall have the right to (...) provide applications and services" (article 3(1)). Par exemple, en France, une mesure de gestion du trafic est mise en place par quelques FAI pour éviter que l'ordinateur de l'utilisateur n'émette des emails afin qu'il ne puisse pas émettre des spams s'il a un virus. En tant qu'utilisateur final, je peux décider de désactiver cette mesure de gestion du trafic afin de proposer un service d'emails légitime depuis mon service d'accès à Internet. En France, des FAIs d'envergure nationale limitent mon droit prévu à l'article 3(1) en m'empêchant d'envoyer des emails depuis mon accès Internet fixe comme Orange or Darty. D'autres FAIs ouvrent le service d'emails en opt-out comme Free or SFR. La dernière approche est la bonne et elle doit être encouragée par les autorités nationales de régulation.
J'approuve les paragraphes 6 et 89 : « NRAs may take into account the interconnection policies and practices of ISPs in so far as they have the effect of limiting the exercise end-user rights under Article 3(1). » et « if there is recurrent and more long-lasting network congestion in an ISP's network, the ISP cannot invoke the exception of congestion management ».
Mais, le BEREC doit clarifier le paragraphe 47 : la mauvaise qualité (capacité, latence, gigue, etc.) d'une interconnexion entre deux FAI incite obligatoirement les utilisateurs finaux à privilégier un service ou une application (la plus rapide) au détriment d'un concurrent techniquement et fonctionnellement équivalent. Dans ce cas, le FAI a limité les choix de l'utilisateur final, ce qui est une infraction à l'article 3(1). C'est encore pire si le service privilégié appartient au FAI.
Les FAIs doivent offrir le même niveau de qualité vers « virtually all end-points of the Internet ». Les autorités nationales de régulation doivent surveiller les interconnexions des FAI et sanctionner les FAI si nécessaire. En France, l'ARCEP travaille sur cette question depuis plusieurs années.
Le paragraphe 47 signifie probablement qu'une interconnexion entre deux FAI n'est pas un service d'accès à Internet pour utilisateur final. Si c'est bien le cas, ce point est OK.
Concernant les services gérés (paragraphes 95-123)Paragraphe 109 : l'exemple de la TV linéaire est un exemple biaisé : en France, les FAIs fournissent leur service de télévision linéaire et leur service de VOD dans un même service géré en considérant que tout ça, c'est de la télévision. Ces FAIs priorisent donc leur propre service de VOD au détriment des services de VOD concurrents. C'est un contournement de l'article 3(3) du Règlement. Les autorités nationales de régulation doivent être vigilantes sur ce point.
Paragraphe 118 : un FAI ne doit en aucun cas limiter la capacité réseau d'un utilisateur final. Cela doit obligatoirement être considéré comme une infraction au Règlement, même si l'utilisateur final est informé (Article 4(1)(c)). Si une limite de la capacité réseau de l'utilisateur final était acceptable, cela signifierait que l'utilisateur final n'a pas voulu souscrire à un service d'accès à Internet mais au service géré donc le FAI n'aurait pas dû vendre un service d'accès à Internet et l'utilisateur final n'aurait pas dû acheter un service d'accès à Internet car ce n'est pas ce dont il a besoin. De plus, en France, les services gérés sont fournis dans un package commercial (nommé « offre triple-play ») à un prix psychologique qui incite l'utilisateur final à ne pas réclamer une offre d’accès à Internet sans service géré. De plus, les offres sans services gérés ne sont pas facilement identifiables dans les catalogues des FAIs.
Cordialement.
Un énorme merci à b4n ( http://ban.netlib.re/shaarli/ ) pour son aide sur la traduction. Merci au groupe de travail « régulation » de la FFDN ( https://www.ffdn.org/fr/ ) pour l'accueil et la motivation.