Article 3(3) second subparagraph “Traffic management measures” Stakeholder responses Some ISPs argued that NRAs should focus on the outcomes of traffic management, rather than monitoring the technical options chosen by each ISP to achieve these outcomes. They stated that, since the Regulation clearly acknowledges the need and right for operators to manage their networks, BEREC should remove wording such as “prima facie, appears to infringe this principle”. However, some CAPs and civil society respondents considered that the content of paragraph 57 (paragraph 54 of the draft Guidelines) did not reflect the letter of the Regulation, which requires traffic management to be transparent, non-discriminatory and proportionate, and would not ensure application-agnostic traffic management (see comments from CAPs and civil society below for further details on this and related arguments). Some ISPs considered that different network management rules should be allowed to apply to different categories of traffic (e.g. 5G) in order to allow development of future technologies and EU policy objectives (e.g. the EU’s Gigabit Society). With regard to innovative IoT/M2M services like connected car services, some industry stakeholders demanded that specific data connections for connected driver assistance systems and automated vehicles must be given priority over other applications that are not relevant for traffic or road safety. These stakeholders are of the opinion that the Regulation provides for two possible ways of implementing the requirements mentioned above: categories of traffic within the IAS and specialised services. BEREC response With regard to the reference in paragraph 57 (paragraph 54 of the draft Guidelines) to a measure “which, prima facie, appears to infringe” the principle of equal treatment set out in Article 3(3) first subparagraph, this was intended to be descriptive, rather than prescriptive. However, having considered the responses from stakeholders, BEREC decided to delete this part of the sentence in order to avoid any misunderstanding. Since this section is meant as an introduction to Article 3(3) second subparagraph, BEREC refers stakeholders to the sections below, in which traffic management measures are discussed in more detail and to section above related to Article 3 as a whole in which BEREC describes the general approach to Articles 3(2), 3(3) and 3(5). Providers are free to also use “categories of traffic” for IoT/M2M services such as connected car services, provided that the conditions of Article 3(3) are met, including to respond to objective technical requirements in line with the Guidelines. BEREC notes that “categories of traffic” should be clearly distinguished from specialised services, as explained in paragraph 75 (paragraph 72 of the draft Guidelines). 21

“Transparent, non-discriminatory and proportionate” Stakeholder responses Some of the CAP and civil society respondents agreed with the provisions relating to the safeguards for encrypted traffic (paragraph 60 / paragraph 57 of the draft Guidelines) and the clarification provided in the Guidelines on “reasonable traffic management”. However, some CAPs and civil society respondents considered that the content of paragraphs 58 and 60 (paragraphs 55 and 57 of the draft Guidelines) did not reflect the letter of the Regulation, which requires traffic management to be transparent, non-discriminatory and proportionate, and would not ensure application-agnostic traffic management (see comments from CAPs and civil society below for further details on this and related arguments). When considering whether a traffic management measure is proportionate in paragraph 61 (paragraph 58 of the draft Guidelines), some civil society respondents also urged BEREC and NRAs to take account of the risk of mis-classification of applications and that this risk will be higher according to the number of traffic classes applied by the ISP. They also argued that, when ISPs are able to use alternative types of traffic management, they should not favour a more intrusive type over a less intrusive type just because the less intrusive type is not “equally effective”. From the perspective of ISPs, they argued that the guidance in paragraph 60 (paragraph 57 of the draft Guidelines) not to treat encrypted traffic differently should be removed or amended since operators cannot recognise the exact type of content (voice, video, gaming), and therefore cannot manage it appropriately. Some ISPs also considered that the factors set out in paragraph 61 (paragraph 58 of the draft Guidelines) to take into account in determining whether a traffic management technique is proportionate were not based on the Regulation and were overly restrictive. They considered that applying overly restrictive criteria will prevent operators from developing new traffic management techniques that could be more effective and provide competitive differentiation. According to these views, the only condition that is required in the Regulation is that traffic management is reasonable and follows the transparency, non-discriminatory and proportionate requirements. They stated that paragraph 61 (paragraph 58 of the draft Guidelines) also implied that operators must provide ex ante justification for a traffic management measure (“evidence to show it will have that effect...”). Therefore, BEREC was advised to delete the third and fourth bullet points in paragraph 58. BEREC was also requested to provide a clear statement that the traffic management assessment/evaluation should be done ex post, rather than ex ante. BEREC response With regard to the treatment of encrypted traffic, BEREC considers that discrimination based on whether or not traffic is encrypted would not be consistent with the Regulation. In the first bullet point of paragraph 61 (paragraph 58 of the draft Guidelines) BEREC refers to the aim of “contributing to an efficient use of network resources and to optimisation of overall transmission quality”. In some of the subsequent bullet points, BEREC referred to “the aim”. Taking into account stakeholders’ responses, BEREC decided to change these references to from “the aim” to “this aim” to clarify that they refer back to the first bullet point. 22

In addition, BEREC modified the text in the second bullet point, changing “will have” to “has”, to avoid the potential misinterpretation that this could refer to ex ante assessment. And BEREC also updated the text in the fourth bullet point to clarify that the bullet point refers to traffic management and not to investing in infrastructure. Otherwise, BEREC considers that the text of this section of the draft Guidelines was consistent with the Regulation and no other amendments were needed. “Objectively different technical QoS requirements of traffic categories” Stakeholder responses Some of the CAP and civil society respondents agreed with the provisions relating to the safeguards for encrypted traffic (paragraph 64 / paragraph 61 of the draft Guidelines). However, some believed the Guidelines need to provide further safeguards to end-users. For instance, some CAP and civil society respondents were concerned that the Guidelines could permit certain types of discrimination, leading to anti-competitive practices, or emphasised their view that the burden of establishing whether a traffic management measure is reasonable should be on the ISP (paragraph 62 / paragraph 59 of the draft Guidelines). In particular, it was argued by CAP and civil society respondents that substantial parts of the Guidelines under Article 3(3) second subparagraph (e.g. paragraphs 63-66 / paragraphs 60- 63 of the draft Guidelines) do not reflect the principles stated in Article 3(3) of the Regulation and would not ensure application-agnostic traffic management. They suggested that traffic management should not focus on categories of applications, and neither on application layer protocols nor generic application type, but rather on broad categories of the traffic’s sensitivity to objective QoS-requirements (e.g. latency, jitter, packet loss and bandwidth). The reasoning provided for this view was based on the wording and intentions stated in the Regulations and because of the risk of potential discrimination amongst applications or types of application. For instance, there was concern the interpretation in the draft Guidelines could lead to intentional or inadvertent discrimination, distort competition, stifle innovation and slow all encrypted traffic. Due to these factors, some of the highlighted risks included potential slowing of internet telephony, misclassification of applications and burdensome negotiation between CAPs and ISPs to try to ensure applications won’t be caught up in traffic management measures. Also, according to these views, BEREC has applied a higher safeguard regarding the more exceptional traffic management measures of Article 3(3) third subparagraph than it has applied to the more conventional measures of the second subparagraph, whereas the latter should be brought into line with the former. However, taking a different view, ISPs suggested that the second sentence of paragraph 64 (paragraph 61 of the draft Guidelines) should be amended as they considered it would not be proportionate to require IAS providers to automatically apply the foreseen network management measures on traffic categories. They alternatively suggested that the paragraph should be amended to allow encrypted traffic to be treated differently (see also comments on paragraph 60 / paragraph 57 of the draft Guidelines). BEREC response This section concerns the stipulation in the Regulation that traffic management should be based on objectively different technical quality of service requirements. Therefore, BEREC 23

decided it would be appropriate to update the text of paragraph 63 (paragraph 60 of the draft Guidelines) to refer to this requirement, as suggested by some stakeholders. BEREC also decided to update the text of paragraph 66 (paragraph 63 of the draft Guidelines) for clarity and to remove some of the specific examples (“such as SMTP, HTTP or SIP”). Taking into account these changes and the ones mentioned above, BEREC considers that the Guidelines are now sufficiently clear that traffic management should be based on objectively different quality of service requirements. With regard to the subject of encryption, BEREC refers stakeholders to the discussion on this subject in the previous section. Taking into account other responses from stakeholders, BEREC also decided to clarify the text of paragraph 67 (paragraph 64 of the draft Guidelines) on traffic used for network management and control. “Not based on commercial considerations” Stakeholder responses Some of the CAP and civil society respondents agreed with the provisions relating to the prohibition on traffic management on the basis of commercial grounds (paragraph 68 / paragraph 65 of the draft Guidelines), although there was also a suggestion to add another example in this paragraph (“...or where the traffic management measure reflects the commercial interest of an ISP that offers or partners with a provider of a certain application.”). However, some ISPs and other industry stakeholders considered that the statement in paragraph 68 (paragraph 65 of the draft Guidelines) that traffic management measures based on commercial grounds “is not reasonable” is too simplistic and suggested rather that they should not be based “only”. They also suggested that it was not possible to exclude commercial considerations from traffic management in the case of IAS provided to business customers. BEREC response Having considered the responses from stakeholders, BEREC decided to add a reference in paragraph 68 (paragraph 65 of the draft Guidelines) to measures that reflect the “commercial interests of an ISP that offers or partners with a provider of certain applications” in order to provide more examples of the potential commercial relationships of ISPs. Otherwise, BEREC consider that the guidance in this section is consistent with the Regulation. “Shall not monitor the specific content” Stakeholder responses Some civil society respondents and other industry stakeholders agreed with paragraphs 69-70 (paragraphs 66-67 of the draft Guidelines), but also suggested adding further references to:    the General Data Protection Regulation (2016/679) and the Directive on privacy and electronic communications (Directive 2002/58/EC);    protection for encrypted traffic;    preference for least intrusive method of traffic management. 24

However, some ISPs argued that IP packet header and TCP header monitoring may not always be sufficient and further monitoring may be necessary while still being generic. For instance, they argued that deep packet inspection (DPI) is used to obtain statistical information (not related to individual customers) to estimate future capacity needs, so should be allowed. They also stated that when the traffic is encrypted, the IAS provider, albeit not negatively discriminating it, will not be able to verify its category in order to know how to treat it. In this way, the BEREC guidance cannot be followed when traffic is encrypted and they suggested that CAPs should be required to disclose the characteristics of their traffic and agree on network management measures with IAS providers. BEREC response BEREC considers that the Guidelines strike an appropriate balance between providing practical guidance for NRAs in accordance with the Regulation whilst not being unnecessarily prescriptive. BEREC also notes that, when defining and using terms, it attempts to explain how it understands those terms. From time to time, BEREC considers it necessary or practical to define new terms that are not used in the Regulation. However, this does not mean that the concepts behind these terms are inconsistent with the principles of the Regulation. In this case, BEREC considered it necessary and appropriate for the Guidelines to interpret what was meant by the “specific content”, which BEREC distinguished from what BEREC understood as “generic content”. “Shall not be maintained longer than necessary” Stakeholder responses With regard to the interpretation of ‘longer than necessary’ in paragraph 73 (paragraph 70 of the draft Guidelines), concerns were raised by CAPs that it is likely to be difficult to differentiate between an admissible ‘trigger function’ for traffic management and inadmissible ‘recurring’ traffic management. As a result, BEREC was advised that this will require regular measurements by the NRA or qualified third parties. Similarly, it was argued that congestion management should be limited to circumstances of unpredictable load at irregular times, not used as a cover for underinvestment in network capacity. However, ISPs and other industry stakeholders were opposed to certain aspects of the provisions in the draft Guidelines. For instance, they argued that paragraph 73 (paragraph 70 of the draft Guidelines) is misleading, would undermine automated network management and seems to question the importance of permanently managing the network for efficiency. They also considered that this paragraph went beyond the Regulation and is not consistent with Recitals 9 and 15, which cover reasonable traffic management and recognise that recurring traffic management can be necessary. Due to these points, they suggested deleting the final sentence of the paragraph and including a reference to the economic viability of extending capacity. BEREC response The Regulation states that in order to be deemed reasonable, traffic management measures “shall not be maintained for longer than necessary”. The Guidelines reflect the importance of taking into account such factors. While providing practical advice for NRAs, the Guidelines do not make any per se prohibitions or prescriptive obligations; rather they focus on how NRAs may consider and assess these issues. 25

However, BEREC decided to update paragraph 73 (paragraph 70 of the draft Guidelines) with some re-phrasing for clarity, where it has been explicitly described that traffic management measures are “effective” on a permanent or recurring basis, whereas their necessity might be questionable. Article 3(3) third subparagraph Stakeholder responses There was strong support from civil society respondents for this part of the draft Guidelines, but there was a suggestion to add another reference to the Data Protection Regulation (2016/679). There was also a suggestion from civil society respondents to change paragraph 78 (paragraph 75 of the draft Guidelines) to allow network-internal blocking by the ISP if it is done at the request of the end-user and is under the control of the end-user, since they considered the most important principle was that the end-user could decide. Similar to this last point, some ISPs and other industry stakeholders suggested certain types of practice that could be interpreted to fall under the categories mentioned such as ad-blocking, filtering or parental controls - are enhancements of end-user service or may be requested or applied by end-users voluntarily. They argued that such features might be unrelated to traffic management. They also suggested that exercising such choice should not be limited to the terminal equipment, as it should be technologically neutral. Therefore, they requested that paragraphs 77-78 (paragraphs 74-75 of the draft Guidelines) were amended to recognise these points. Another suggestion from some civil society respondents and ISPs was for NRAs to support ISPs blocking content recognised as illegal under Union law or national legislation (as also referred to in paragraph 81 / paragraph 78 of the draft Guidelines), on a voluntary or self- regulatory basis, making reference to Recital 13. For the specific case of child sexual abuse content, a reference to Directive 2011/92/EU of 13 December 2011 combating child sexual abuse was suggested. It was also suggested that NRAs should also support the ability of ISPs to filter spam at any time. BEREC response With regard to some of the suggestions made by stakeholders about traffic management features that could be requested or controlled by end-users, BEREC notes that the Regulation does not consider that end-user consent enables ISPs to engage in such practices at the network level. End-users may independently choose to apply equivalent features, for example via their terminal equipment or more generally on the applications running at the terminal equipment, but BEREC considers that management of such features at the network level would not be consistent with the Regulation. With regard to some other requests to include additional references, in particular to content recognised as illegal, BEREC considers that these matters are sufficiently covered elsewhere, in particular under Article 3(3) (a) and the corresponding section of the Guidelines. BEREC also notes that these issues would require an approach based on legislation, rather than being voluntary or self-regulatory. 26

Article 3(3) (b) Stakeholder responses Some civil society respondents raised some issues regarding the Guidelines under Article 3(3) (b). For instance, they suggested that BEREC clarifies the reference to “recognised security organisations” in paragraph 85 (paragraph 81 of the draft Guidelines) by providing a set of criteria or examples in order to appropriately identify such organisations. They also considered that pro-active, continuous security measures of the kinds referred to in paragraphs 84 and 85 (paragraphs 80 and 81 of the draft Guidelines) should not be permitted, arguing that such measures are not consistent with the provisions of Article 3(3) third subparagraph and would involve processing personal data to a greater extent than allowed by Article 3(4). There was, however, strong support from some civil society respondents for paragraph 87 (paragraph 83 of the draft Guidelines) regarding the risk of a “broad concept” of security being used to circumvent the Regulation. Some civil society respondents, CAPs, ISPs and other industry stakeholders welcomed the provisions in the draft Guidelines which permit networks to filter traffic in order to “protect the integrity and security of the network”, and in particular the recognition of the importance of filtering spoofed addresses (Article 3(3) b) – an important technique for preventing common forms of denial of service (DoS) attack. However, they believed that the guidance that the traffic management measure is triggered only when security attacks are detected (paragraph 85 / paragraph 81 of the draft Guidelines) would counter long standing best practice for the prevention of source-address spoofing (detecting and blocking packets with spoofed source addresses before they leave the network of origin), and thereby to significantly undermine efforts against DoS attacks. They believe that permanent filtering of spoofed addresses should not in any way undermine network neutrality, and therefore urge BEREC to interpret source address spoofing as an attack upon the network in its own right, and that accordingly network operators may continue to maintain filters that identify and block source-spoofed packets whenever they occur. More generally, some civil society respondents and ISPs considered that the text of paragraphs 83-84 (paragraphs 79-80 of the draft Guidelines) would weaken the ability of operators to fight against piracy or security problems. For instance, it was considered that it may leave ambiguous, or constrain, some forms of ISP action to preserve security and restrict spam/malware. BEREC response The draft Guidelines had intended to draw a distinction between the monitoring of traffic to detect security threats and the action that is taken when they are detected. However, taking into account the responses from some stakeholders, BEREC considered it appropriate to rephrase part of this section to provide greater clarity. For instance, in paragraph 85 (paragraph 81 of the draft Guidelines), in cases where security measures have to be active on a continuous basis in order to achieve their purpose (such as filtering of spoofed IP addresses), such measures should be deemed to be justified. The Guidelines are also updated in the same paragraph to allow security measures to be applied only when “concrete” security threats are detected. 27

With regard to the requests to clarify how to identify “recognised security organisations”, this is a matter that will be determined at the national level. Article 3(3) (c) Stakeholder responses There was strong support from civil society respondents for the draft Guidelines’ approach to preventing impending network congestion and mitigating the effects of exceptional or temporary network congestion. Some civil society respondents and ISPs argued that, based on an interpretation of paragraph 92 (paragraph 88 of the draft Guidelines), NRAs will get involved in the decisions of ISPs on how to dimension their networks. They considered this would not be proportionate and would be potentially intrusive into ISPs’ operations and is not foreseen by the Regulation. It was also stated that congestion may arise regularly in an “appropriately” dimensioned network as a result of the actions of a minority of users (e.g. P2P filesharers), and should not always require investment. BEREC response Consistent with Article 3(3) (c) and Recital 15, in the case of ISPs using measures that go beyond what would be considered “reasonable traffic management measures”, NRAs would be empowered to assess whether such measures are recurrent or long-lasting, whether capacity expansion would be economically justified and whether equivalent categories of traffic are still treated equally, and this is reflected in the Guidelines. However, taking into account the responses from stakeholders, BEREC rephrased paragraph 93 (paragraph 89 of the draft Guidelines) in order to emphasise that this would be specifically part of an NRAs’ scrutiny of congestion management practices, rather than a general expectation for NRAs to assess the dimensioning of ISPs’ networks. Article 3(4) Stakeholder responses Some of the CAP and civil society respondents agreed with the provisions on the necessity and proportionality tests (paragraphs 94-97 / paragraphs 90-93 of the draft Guidelines). However, there were suggestions made among the CAP, other industry stakeholders and civil society respondents to include guidance and optional consultation with the European Data Protection Supervisor (EDPS) and Data Protection Authorities in the member states. It was noted that NRAs may not be empowered to enforce data protection legislation, so these bodies could be consulted by NRAs when they assess the privacy and data protection related impacts of traffic management. BEREC response BEREC modified paragraph 98 (paragraph 94 of the draft Guidelines) on “Compliance with Union law on data protection” to ensure that there is not an expectation for NRAs to assess an issue on which they are not empowered to intervene. The identification of appropriate competent authorities in each country will depend on national legislation. 28

BEREC cannot provide guidance on specific types or cases of processing of personal data. Any assessment by the competent authorities of the processing of personal data will have to consider its necessity and proportionality and take into account compliance with Union law on data protection. Article 3(5) first subparagraph Stakeholder responses There was concern from many of the CAP and civil society respondents about over-use of specialised services. According to some, this could lead to unwarranted application-specific traffic management and the establishment of internet ‘fast lanes’ and could be detrimental to start-up innovation in Europe, whereby large or established companies can pay for prioritised service whilst small or new entrants might be unable to overcome the barriers this imposes for competing. A risk to media pluralism was also highlighted. Taking into consideration these concerns, several of the respondents approved of the approach taken towards specialised services in the draft Guidelines and stated that the draft should not be ‘watered down’ in this regard. However, others argued that changes were needed in the Guidelines in order to provide appropriate protection. For instance, there was a suggestion to rephrase paragraph 98 (paragraph 94 of the draft Guidelines) to address the reference to “relatively high quality application”, which was considered confusing, and to slightly redraft paragraphs 102-104 (paragraphs 98-100 of the draft Guidelines) for clarity/emphasis. Some CAP and civil society respondents were in favour of emphasising that there should be checks (ex ante) to ensure that optimisation was objectively necessary and that required quality levels (i.e. not just “stated quality levels”) could not be met over the normal internet. Some also argued that NRAs should check whether ISPs had followed industry practice in expanding network capacity and that the possibility of offering specialised services did not provide an incentive for lack of investment in general capacity. Similarly, they suggested that the Guidelines should include how to assess whether there is sufficient capacity for IAS when specialised services are provided, which they suggest could be assessed based on the frequency/extent of congestion. Alternative views were expressed by ISPs. For instance, they stated that paragraph 98 (paragraph 94 of the draft Guidelines) contradicts Recital 16 of the Regulation (“there can be demand” vs. “there is demand”) and requested clarification of this paragraph. Some ISPs and other industry stakeholders stated that the reference to “objectively necessary” is not in Article 3(5) or Recital 16. Some ISPs emphasised their view that assessment on whether the conditions have been met to provide specialised services can only be performed ex post (relevant for paragraphs 101, 107-108 and 111 / paragraphs 97, 103-104 and 107 of the draft Guidelines). Some ISPs suggested deleting paragraph 104 (paragraph 100 of the draft Guidelines), since it was seemed to create uncertainty and imply that NRAs should decide what level of quality 29

is necessary and not the market. It was also noted that NRAs already have the ability to request information, which is covered in paragraph 108 (paragraph 104 of the draft Guidelines). Similarly, some ISPs and other industry stakeholders argued that the draft Guidelines go beyond the Regulation by creating new conditions for offering specialised services. They argue that the optimisation or level of quality may depend on the needs or demands of end-users, for instance whether they request quality assurances or SLAs. They considered that this does not mean that the service could not necessarily be provided over the IAS, just that the quality assurance could not be provided. They argue that these points are clear in Recital 16, but the Guidelines introduce new conditions that would limit the specialised services to those not already delivered as best efforts services. Therefore, they recommend rephrasing part of paragraphs 105 (paragraph 101 of the draft Guidelines referring to (“…whether the application is delivered at the agreed and committed level of quality, or whether they are instead…”). As stated in the section above related to Article 3(3) second subparagraph, some industry stakeholders highlighted that the Regulation provides for two possible ways of implementing the requirements of innovative IoT/M2M services such as connected car services: categorisation of traffic within the IAS and specialised services. BEREC response With regard to questions about ex ante or ex post assessment, BEREC refers stakeholders to the introductory section on Article 3 in which BEREC discusses this over-arching issue. Having considered stakeholders’ responses, BEREC decided to modify paragraph 99 (paragraph 95 of the draft Guidelines) for greater clarity. In particular, BEREC deleted the reference to “a relatively high quality”, which was potentially confusing. BEREC also decided to delete the reference to “a category of electronic communication”, since this may not have been an accurate description when referring to services delivered as specialised services. Consistent with the Regulation, NRAs are empowered to assess whether and to what extent the optimisation of specialised services is objectively necessary. NRAs would have to assess whether this is the case relative to the quality levels that could be achieved via the IAS. Therefore, the reference to “whether the application could be provided over the IAS” in paragraph 105 (paragraph 101 of the draft Guidelines) is a necessary part of an NRA’s assessment. Some stakeholders were concerned whether quality assurances would be taken into account. BEREC understands that the ability to provide assurances, for instance through SLAs, would be an important aspect of contracts in order to agree not just an expected level of quality but a certain level of consistency or reliability. BEREC considers that the Regulation incorporated such an understanding of “levels of quality”, as do the Guidelines, and it is therefore not necessary to modify this aspect of the Guidelines. However, taking into account other comments from stakeholders, BEREC decided to modify paragraph 105 (paragraph 101 of the draft Guidelines) in order to refer to “specific levels of quality” and “objectively necessary”, which are more in line with the wording of the Regulation. 30