[connect-wg] Fwd: Re: BEREC consultation: contribution

I am trying to absorb Steve Nash's comments have not yet gotten to absorbing
the original BEREC text :-)
{Or, in IETF microphone speak. "I haven't read the draft, but..."}

My high-level take (which I haven't managed to formulate) is that we must
ask/counsel that in the different connection points, what the expected
ownership of liability is. Maybe that's a "US"-centric point of view, so my
understanding is the European view would ask: "who does the regulator fine".


Steve Nash <Steve at nashfamily.me.uk> wrote:
    > *BEREC connection point C:*

    > (Where the NTP has a routing function or NAT, IP aware)

    > The NTP must indicate via its customer port, using IETF standard routing
    > protocol, what connections it is offering /{list of minimum customer
    > selectable protocols?}/. It must withdraw those routing announcements as
    > quickly as the standard allows in the event that its peer router in the
    > network becomes unavailable.

So, *today* the list of "IETF standard routing protocol" in the home is
DHCPv4. That's all.

I.e. you either get a default route or you don't.  And, if DHCPv4 is
withdrawn, all communication in the home tends to cease, because despite IPv4
Link-Local addresses (169.254.0.0/16), many devices consider the lack of
DHCPv4 to mean the network is useable. In particular phones, which means you
can't talk to the lights with the phone app.

In an RFC7084 situation with IPv6, we expect IPv6 to continue to function,
and withdrawal here means no longer advertising a GUA (ULA only) via RA.
In a HOMENET future, this can mean BABEL and HNCP too.

I don't know whether this belongs in a RIPE response.
I do think that that there more interesting question is who has the liability
in each case.

    > Rationale

    > 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.
    > Automated resilience of Internet connectivity becomes increasingly important
    > as:

    > * home working becomes more prevalent
    > * critical devices such as medical appliances and alarm systems are
    > connected in the home via the Internet

    > Therefore resilience for Internet connectivity must be considered in
    > regulation with respect to both Network selection and power supply
    > resilience, as follows.

I agree with this statement, and RFC7084 is really bad for doing this.
HOMENET aimed to solve this; do you think that there is something a regulator
can do to make this better?

    > *Network selection:*

    > On the PSTN the existence of Dial-tone has been the indication of
    > availability at the NTP.
    > A home can easily have more than one PSTN NTP, and more than one fixed line
    > connection to the Internet in addition to mobile.
    > 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.
    > Methods are dependent on the chosen logical Network Termination Point and are
    > proposed in the Summary above.

Sure sounds like HNCP and BABEL is required :-)

    > *Power supply resilience:*

    > 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.

Agreed...!

    > 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.

    > 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.

That would be awesome.

--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/connect-wg/attachments/20191023/41c7fdbf/attachment.sig>