[iot-discussion] What role does the SP play in protecting consumers re IoT?

So keeping the frame in mind: potential problems relate to “things” attached to your home network and what your access provider can and should do about those problems.


> On 19 Apr 2017, at 23:37, Patrik Fältström <paf at frobbit.se> wrote:
> 
> On 19 Apr 2017, at 11:02, Gordon Lennox wrote:
> 
>> Anyway I am very wary of giving more control to access providers, of allowing them to take more control, for a number of reasons.
> 
> For me one reason is enough:
> 
> The basic rule for anyone carrying communication is to carry that communication to the intended destination. As soon as we want exceptions to that rule and responsibility it really really really must be viewed as such. And implemented as such.
> 
> Who makes the decision on when where and why to act, how to ensure the pointy tool used is pointy enough, secondary effect, false positives and such.
> 
> Once again: the main task for a carrier of communication is to do their job to carry the communication.
> 
> Can we agree on that?

But your access provider does not and cannot provide end-to-end communication. That is not what it says in your contract with them.

As a way of moving conversations forward I used to ask people what their ISP did for them. The set of elements I had in mind then has changed. Which is why, in addition to various discussions on "network neutrality”, I now tend to talk about access providers. 

My access provider forwards packets “best effort”. They do not do email for example. Nor chat. Nor… But even with email we both now somebody who has configured their mail server to refuse connections from the email provider I use.

(They also try to run my home network which is irritating.)

So an access provider’s prime role is to do what is written on the tin: forward packets without discrimination or interference or monitoring?

Except various groups want some of those “features" implemented. 

It is a real pity that RFC 3514 did not get more uptake. ;-)

>> Maybe the IP layer is just not where we should be looking for the solution to specific problems.
> 
> Maybe, maybe not?

I think not in general, and probably not in this case. But I would be happy to hear of informed opinions going in another direction.

>> And responding to Patrik’s bullets - because I have too! ;-)
> 
> :-D
> 
>> A. Sort the quality problem. Yes please. But how come big resource-rich companies - make your own list - are patching and patching and then patching again. Until end-of-life? I am not clear what we ought to be able to expect from the rest.
> 
> Bingo!

And then what?

>> B. Stickers, seals, logos, MoUs have been popular for a long time. One more? Some more?
> 
> I do not know, thats why I asked! :-D
> 
>> C. I don’t think the Parliament is going to be that happy recommending that an access provider can cut off a domestic customer suddenly and completely. An awful lot of safeguards would be required. And even then.
> 
> Yes, agree. See above on the role of the communication provider.
> 
>> D. Public procurement? It would be nice if that was done better from an internet engineering perspective. But public procurement is political. The big battles have tended to be around local preference rather than IPv6. Looking back though we have tried to make the technical rules clearer, both in terms of interconnection and security. GOSIP? Common Criteria? And much more. And we have had national successes which were both good and bad - good for a time and then bad? But if you want to enforce rules then you need a body to make those rules. Sorry Patrik but just asking you is not an option. ;-) So who? ETSI? CENELEC? And I feel not the IETF. RFCs provide “advice to consenting engineers": they are not always ideal procurement specs.
> 
> Well, I would not mind having some wrong requirements sometimes. That is why I rather see requirements in procurements than in legislation... And we should not mix up historical bad regulation with procurement requirements.

There are always restrictions in procurement. Offering bribes tends to be always out. But here we are talking about public procurement and here the barriers are a bit higher. And if you are going to write rules for public procurement then it can be useful to have a reference base of technical standards from recognised standards organisations. Which is why I cited ETSI and CENELEC.

There have been attempts to get around this by talking about “pre-competitive procurement” as a fellow countryman of yours proposed.

But, wonderful as it could be, you cannot just say: propose stuff that the internet community, including the IETF and W3C and the RIRs and Patrik and all, think is fine.
 
>> See you at 74.
> 
> Not me :-(
> 
>   paf

Pity.

Gordon