This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/connect-wg@ripe.net/
[connect-wg] BEREC consultation: contribution
- Previous message (by thread): [connect-wg] BEREC consultation: contribution
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Michael Richardson
mcr+ietf at sandelman.ca
Fri Oct 25 20:12:37 CEST 2019
EXEC SUM: ** I think that you are looking for text that addresses the net-neutrality and ** privacy implications of each attachment point, and leave it to legislators to ** figure out which one is best. Marco Hogewoning <marcoh at ripe.net> wrote: >> On 23 Oct 2019, at 22:04, Michael Richardson <mcr+ietf at sandelman.ca> wrote: >> >> 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”. > To Micheal’s question and some other comments regarding the expected > outcome. I don’t think at this stage BEREC is aiming to get a single > solution, the draft lists a few different options and I expect that > most will remain in the final version. My current assessment is that > they are mostly seeking feedback on the rationale for the different > scenarios and the criteria under which diversions from a particular > ruleset are allowed. Yes, I understood this was the goal. Thus my difficulty in figuring out how to get from what I care about, to what they care about. That's why I'm coming at it at big wrong. I care about: 1) protecting the right for the resident to connect any home router. 2) protecting the view that the home router must be controlled by the resident. 3) the home router has to be involved in securing the home, and this means disclosing to the home router a list of all devices in the home... so privacy. 4) the universal deployment of IPv6 Note that I said home router, while the term "CPE" is usually meant to mean a device owned and controlled by the ISP. (Their demarcation point) For many IPv4-centric non-gamers, they would be perfectly fine having a full router CPE, with their own home router behind that, doing double NAT, and no IPv6. IPv6 users and those who want good gaming response, the lack of UPnP and IPv6 is a big deal. Unfortunately, RFC7084 does not mandate DHCPv6-PD on the LAN side of the router, and short of a full-homenet HNCP/BABEL deployment (which I would dearly like...), this means that IPv6 will not flow into the second router. Some solutions are: 1) don't have stupid two-layers of routers. Let the resident into at least some part of the CPE, perhaps involving containers (maybe even Trusted Execution Environments) to isolate the different concerns. 2) write a document mandating LAN-side DHCPv6-PD for all CPEs. 3) mandate CPEs support L2-passthrough, effectively splitting the "modem" and the "router" parts. Each of these solutions provides much clearer view as to "who to fine" as well. > I don’t feel this is about “who to fine?”, obviously in the end this is > about regulation and there might be repercussions for entities that are > found in breach of the law. However this is not in BEREC’s mandate at > the moment. The aim for this process, and BEREC’s role here, is really > to create some consistency in interpretation of this directive and the > resulting legislation, also in how to resolve conflicts with other > texts. Especially since it rubs against some other directives, most > importantly the net neutrality one, which might be a source of conflict > where one directive says A and the other says B. There must also be some privacy directives that conflict. Having DNS lookups in the ISP-controlled device could be a privacy breach. Having a list of devices in the home in a ISP-hosted database (via TR-069) has got to have privacy implications. Putting the boundary in the right place solves these. I am not at all an expert on these other directives. I am good at wrangling text, but I don't think that I can read up on the directives in sufficient time to address them directly. ** I think that you are looking for text that addresses the net-neutrality and ** privacy implications of each attachment point, and leave it to legislators to ** figure out which one is best. I just want to see progress on the direction of who is liable for attacks by rogue Things, so that the relevant parties can be persuaded to make the right investments. In particular, the ISPs have not had a good track record in the past of actually investing in security patches for their devices. prplFoundation had a meeting this week in Berlin, which I did not make, and I wonder if they had an opinion. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- 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: </ripe/mail/archives/connect-wg/attachments/20191025/fd4efb73/attachment.sig>
- Previous message (by thread): [connect-wg] BEREC consultation: contribution
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]