<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <div class="moz-forward-container">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p><font size="-1">I have only partially absorbed all aspects of
          the BEREC document and EU Article61, but my impression is of
          some important missing elements.  In particular, I have not
          noticed references to co-habitation of multiple NTP in one
          customer site.   The subject of resilience seems missing.<br>
        </font></p>
      <p><font size="-1"> </font></p>
      <p><font size="-1">BEREC has given us a simple model on which to
          comment, with three levels of NTP.  Rather than defining what
          an NTP must always be, I prefer to consider what a customer
          needs from the NTP regardless of its logical location.</font></p>
      <p><font size="-1">Given that we are RIPE, and given the absence
          of any bidirectional Public Data Communication Network other
          than the Internet, I focus my comments accordingly.</font></p>
      <p> </p>
      <h2 class="western"><font size="-1">Summary</font></h2>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">Whatever the point of delivery of the Network
          connection, there must be clear signalling of whether or not
          the provision of Network connection is functional.</font></p>
      <font size="-1"> </font><font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">For Internet Access the NTP must indicate the status
          of its connection to the Internet. The form of the indication
          is considered next for each of the BEREC logical Termination
          Points. <br>
        </font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"> </p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm"><font size="-1"><b>BEREC
            connection point C:</b></font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">(Where the NTP has a routing function or NAT, IP
          aware)</font></p>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">The NTP must indicate via its customer port, using
          IETF standard routing protocol, what connections it is
          offering <i>{list of minimum customer selectable protocols?}</i>. 
          It must withdraw those routing announcements as quickly as the
          standard allows in the event that its peer router in the
          network becomes unavailable. </font></p>
      <font size="-1"> </font><font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><b>BEREC connection point B:</b></font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">(Where the connection is provided at a modem port,
          Ethernet or WiFi)</font></p>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">The network must provide signalling of its status to
          the user. The user must be provided with:</font></p>
      <ul>
        <li><font size="-1">visibility of the adjacent router(s) by
            routing protocol announcements from the operators
            router(s).  The list of offered routing protocols being a
            required part of the service description. <br>
          </font></li>
        <li><font size="-1">the IP address delegated by the operator for
            the CPE, manually or by DHCP.</font><font size="-1"><br>
          </font></li>
        <li><font size="-1">the permanence of the IP address delegation</font><font
            size="-1">  (Static or Dynamic)<br>
          </font></li>
        <li><font size="-1">the IP address of the adjacent router(s) in
            the provider's network, to enable security filtering</font></li>
      </ul>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><b>BEREC connection point A:</b></font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm; font-weight: normal"
        align="LEFT"><font size="-1">(Where the connection is by wired,
          optical or wireless Ethernet) <br>
        </font></p>
      <p class="western" style="margin-bottom: 0cm; font-weight: normal"
        align="LEFT"><font size="-1">The Network must offer DHCP for the
          customer's delegated address, and the address of the available
          Network router.</font></p>
      <p class="western" style="margin-bottom: 0cm; font-weight: normal"
        align="LEFT"><font size="-1">The Network may offer IP routing
          protocols, as for connection point B.</font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm; font-weight: normal"
        align="LEFT"><font size="-1"> The physical Signal must be
          withdrawn at the physical layer when the Network is otherwise
          unable to communicate loss of routes ( for comparison consider
          removal of dial tone). </font></p>
      <font size="-1"> </font><font size="-1"> </font><font size="-1">
      </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><br>
        </font> </p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><b>Other Requirements:</b></font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">1/ In cases B and C, user-configuration of the
          characteristics of the user port must be supported. Including
          Local MAC address, Local IP address, Local default router,
          Local routing protocol, as applicable. <br>
        </font></p>
      <p><font size="-1"><br>
        </font></p>
      <p><font size="-1">2/ It must be contractually clear whether an
          Internet Connection service at an NTP is fully open, or in
          some way restricted.</font><font size="-1"> </font><font
          size="-1">A fully open Internet Connection will have a public
          IP address capable of end to end communication with any other
          public Internet address on the same version of IP.  This would
          facilitate the customer in supporting an Internet Server, if
          they so choose.</font></p>
      <font size="-1">Restrictions that make the connection less than a
        fully open Internet connection must be disclosed in the
        documentation of the connection service, and include:</font><br>
      <font size="-1"> </font>
      <ul>
        <li><font size="-1">Network Address Translation, either in the
            network (CGN) or on supplied NTP.</font><br>
        </li>
        <li><font size="-1">Blocking of access to some Internet
            addresses (as has sometimes been the case for open DNS
            resolvers).</font><br>
        </li>
      </ul>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">3/ Power Supply resilience for network devices
          becomes increasing important. Consideration should be given to
          regulation of common low power battery backup supply
          connection for all NTP.</font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><br>
        </font> </p>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"> </p>
      <font size="-1"> </font>
      <h2 class="western"><font size="-1">Rationale</font></h2>
      <font size="-1">Most homes in the EU have more than one Network by
        which to access the Internet, commonly one fixed and one or more
        mobile. The NTP of each Network must allow for the existence of
        others and must enable the customer to program decisions about
        which Network to use.</font><font size="-1"> </font><font
        size="-1"> </font><br>
      <font size="-1">Automated resilience of Internet connectivity
        becomes increasingly important as:</font><br>
      <font size="-1"> </font>
      <ul>
        <li><font size="-1">home working becomes more prevalent</font><br>
        </li>
        <li><font size="-1">critical devices such as medical appliances
            and alarm systems are connected in the home via the Internet</font><br>
        </li>
      </ul>
      <font size="-1"> </font><font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">Therefore resilience for Internet connectivity must
          be considered in regulation with respect to both Network
          selection and power supply resilience, as follows.</font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><br>
        </font> </p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><b>Network selection:</b></font></p>
      <font size="-1"> </font><font size="-1">On the PSTN the existence
        of Dial-tone has been the indication of availability at the NTP.</font><br>
      <font size="-1">A home can easily have more than one PSTN NTP, and
        more than one fixed line connection to the Internet in addition
        to mobile. </font><br>
      <font size="-1">Therefore, customer owned equipment must have the
        opportunity to be able to directly determine, in an automated
        fashion, whether or not connectivity via each Internet
        Connection Provider is functional. </font><br>
      <font size="-1">Methods are dependent on the chosen logical
        Network Termination Point and are proposed in the Summary above.
      </font>
      <p><font size="-1"> </font></p>
      <font size="-1"> </font><font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1"><b>Power supply resilience:</b></font></p>
      <font size="-1">Logical termination equipment (e.g. modem) may be
        required for some physical access media. If power is not
        supplied from the network then the customer's domestic supply
        may be used. In the latter case the regulator must give
        consideration to backup supply standardisation. </font><font
        size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">The proliferation of individual AC to DC power
          converters and the need for Inverters to get back to AC supply
          levels from battery backup is not energy efficient.</font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">Standardisation of low power DC supply to NTP
          devices would reduce electrical wastage and could reduce the
          number of manufactured components required where devices are
          permanently powered with DC. </font></p>
      <font size="-1"> </font>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">Steve Nash</font><br>
      </p>
      <p class="western" style="margin-bottom: 0cm" align="LEFT"><font
          size="-1">Writing my personal opinions, with the Sponsorship
          of NETSCOUT.<br>
        </font> </p>
      <font size="-1"> </font>
      <p><br>
      </p>
      On 10/10/2019 17:52, Marco Hogewoning wrote:<br>
      <blockquote type="cite"
        cite="mid:8A4C1B8C-5484-40BB-86EA-1DA77C58FF6C@ripe.net">
        <pre class="moz-quote-pre" wrap="">Dear colleagues,

Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation.

This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security.

We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses.

I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website:
<a class="moz-txt-link-freetext" href="https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/8821-berec-guidelines-on-common-approaches-to-the-identification-of-the-network-termination-point-in-different-network-topologies" moz-do-not-send="true">https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/8821-berec-guidelines-on-common-approaches-to-the-identification-of-the-network-termination-point-in-different-network-topologies</a>

Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus.

Key Issues

One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1):

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">“End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]”
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state:

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">“In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’.

Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.”
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist.

As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term.

There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network.

The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6.

We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption.

We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability.

In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption.

More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion.

Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer.

In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users.

Regards,

Marco Hogewoning
External Relations, RIPE NCC


_______________________________________________
connect-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:connect-wg@ripe.net" moz-do-not-send="true">connect-wg@ripe.net</a>
<a class="moz-txt-link-freetext" href="https://mailman.ripe.net/" moz-do-not-send="true">https://mailman.ripe.net/</a>
</pre>
      </blockquote>
      <div class="moz-signature">-- <br>
        <a class="moz-txt-link-abbreviated"
          href="mailto:Steve@nashfamily.me.uk" moz-do-not-send="true">Steve@nashfamily.me.uk</a>
        is now my personal email address.</div>
    </div>
  </body>
</html>