[Chapter-delegates] ISOC open letter

[Richard Hill]

Dear Andrew,

Thank you for this. Please see embedded comments below.

Best,
Richard

> -----Original Message-----
> From: Chapter-delegates [mailto:chapter-delegates-
> bounces at elists.isoc.org] On Behalf Of Andrew Sullivan via Chapter-
> delegates
> Sent: Thursday, 20 May 2021 16:23
> To: chapter-delegates at elists.isoc.org
> Subject: Re: [Chapter-delegates] ISOC open letter
> 
> Hi,
> 
> On Thu, May 20, 2021 at 11:53:43AM +0200, Richard Hill via Chapter-
> delegates wrote:
> 
SNIP

> 
> >As I've said before, the Internet Way of Networking appears to me to
> apply
> >mainly to infrastructure
> 
> I know you have said this, and I think I have asked what you mean by
> "infrastructure".  

I think that RFC1122 is relevant here, see:

  https://www.ietf.org/rfc/rfc1122.txt 

 
https://en.wikipedia.org/wiki/Internet_protocol_suite#Key_architectural_prin
ciples 

To me, the Link, Internet, and Transport layers are for sure infrastructure.
Some parts of the Application layer might be infrastructure, but much of it
is not.

>The basic problem with that line of argument is that
> it suggests, without quite saying, that there is a bright line where one
> can say, "This is not infrastructure."  

No, there is not a bright line. Still I think that most people would agree
that, at least at present, e-commerce platforms, streaming services, and
social media are not infrastructure.

>But that turns out to be false,
> because of the way the Internet encourages encapsulation and component
> re-use.

Maybe I'm missing something, but I haven't seen encapsulation and component
reuse in those parts of the Application layer which are not infrastructure,
e.g. e-commerce platforms, social media, streaming services.

> 
> The basic trouble here is that the idea of tidy "layers" (often somehow
> derived from the OSI model) is really a fiction.  From very early on,
> infrastructure was found in the application layer -- DNS is clearly an
> application even though virtually nothing else works without it.

Indeed DNS is in the Application layer, but I would consider it to be
infrastructure.

>  Is
> quic a transport or application-layer technology?  In some sense, it's
> both and neither.  And of course, huge chunks of the Internet (not just
> the Web) depend on authentication services that are deeply embedded in
> certain social medial platforms.

Authentication services are also, for me, another example of infrastructure
at the Application layer.

> 
> >Regarding the issue at hand, if some company uses the Internet to
> provide
> >what is in effect a broadcast service, then it might make sense to
> regulate
> >that service just like any other broadcast service.
> 
> It might, if the tidy category "broadcast" would stay still.  But it
> doesn't, 

I'm not sure what you mean by that. For sure the technologies used to
broadcast evolve, but the basic concept is the same: to use some medium to
send the same content to a lot of people more-or-less at the same time, see:

  https://en.wikipedia.org/wiki/Broadcasting 

In some instances (e.g. Swiss TV), the Internet is being used a broadcast
medium.

>and efforts by the Government of Canada to fix these boundaries
> are as likely as not to require network and network-services operators
> to impose (in Canada's case, even more) arbitrary sludge on the network

You seem to assume that technical changes would be required to achieve
certain regulatory goals. But that's not always the case.  Take the DNS as
an example. In the early days, some people thought that trademark law did
not apply to domain names. That belief was rapidly dispelled. But it didn't
require any technical changes to apply trademark law to domain names. All
that was required was for courts to apply trademark law, and, for the sake
of efficiency, to create a special procedure to deal with blatant abuses:
the UDRP.

I'm still not clear regarding what "sludge" would be required to comply with
what bits of the proposed Canadian regulations.

> in an effort to conform with poorly-conceived directives from a
> regulator that doesn't always seem to have a solid grasp of the nature
> of the Internet.

That can be turned around: some technologists don't always seem to have a
solid grasp of the nature of offline laws that, as we know, apply equally
online.

> 
> >> The only practical ways anyone has been able to understand most of
> the
> >> provisions (and they're not all in the bill, because a number of the
> >> rules would actually have to be made up by the CRTC after the bill
> >> became law) involves mucking with the operation of networks
> themselves
> >> in order to implement the goals.
> >
> >Could you be more precise? What sort of "mucking"?
> 
> Network service providers who are subject to fines if something contrary
> to a regulation happens inevitably make the thing at least hard to do in
> the network.  This kind of activity implicitly turns the Internet from a
> general-purpose technology to one directed at specific purposes, 

As far as I can tell, most of the Application layer is specific-purpose,
e.g. e-commerce platform, social network, streaming service,
some-sort-of-scheme to collect personal data so as to be able to sell
targeted advertising, etc.

>and
> increases complexity as a result.  Obvious examples include various DNS-
> based filters that get deployed and the ubiquitous use of geolocation
> for service-provision determination.

I agree that these are troublesome developments. But, as far as I can tell,
at least geolocation was invented less due to government regulation than to
a desire to improve the specificity of targeted advertising.

SNIP