Subject: Re: [hrpc] Draft: Rights for restricted content

From: Mallory Knodel <[email-masked]>
Date: Wed, 15 Aug 2018 10:20:48 +0300

> On Thu, Jul 19, 2018 at 03:54:12PM +0200,
>  Amelia Andersdotter <[email-masked]> wrote 
>  a message of 44 lines which said:
> 
>> Is this an assessment of the technical feasibility of the draft, or
>> are you objecting to the underlying problem formulation that the
>> draft is trying to solve through technical means?

On 19/07/18 17:04, Andrew Sullivan wrote:
>
> The clue that the technical feasibility approaches zero is contained
> in the first sentence of section 3.2: "In order to track the route of
> carriers involved…."

On 19/07/18 17:33, Stephane Bortzmeyer wrote:
> The biggest problems are of course political (sending money to the
> transit providers, and trying to define rights in the links) but there
> are indeed big technical issues:
> 
> * #1 is that experience in hypertext has clearly shown that adding
> metadata in the link is brittle because, when the target changes,
> there is no way to list all links pointing to it, and therefore to
> modify them (if I remember correctly, this was one of the reasons Tim
> Berners-Lee's original article about the Web was rejected, since the
> craze at this time was bidirectional links). This is specially
> critical here since "rights on content" are quite changeable. So,
> "rights" and/or permissions must stay on the origin site, not be put
> in the links (except for stupid ideas like "link tax").
> 
> * the draft is specific to HTML links instead of using the more
> general link framework of RFC 8288.
> 
> * TCP options cannot be relied on
> <https://www.imperialviolet.org/binary/ecntest.pdf>, unfortunately.

Hi all,

Above is a complied list of feedback for the author. He did write back
to Stephane and me and attached is what he said in one of his messages.

I think someone ought to take what is above and send it as an actual
review and be done.

-Mallory

-- 
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780

Subject: Re: [draft-donnerhacke-linktax] Available in Montréal?
From: Lutz Donnerhacke <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
Cc: Lutz Donnerhacke <[email-masked]>, Mallory Knodel <[email-masked]>
Date: Sun, 22 Jul 2018 23:37:07 +0200

On Mon, Jul 16, 2018 at 11:17:14AM -0400, Stephane Bortzmeyer wrote:
> I participate to the Human Rights Review Team
> <https://www.irtf.org/mailman/listinfo/hr-rt> and your draft
> draft-donnerhacke-linktax caught our eye. Are you in Montréal to
> discuss it AFK?

I'm just back from vacation (without Internet access).
More correctly: I'm back to Internet access, but still on vacation.

> Technically, I see at least several issues:
> 
> * why make it specific to HTML links instead of using the more general
> framework of RFC 8288?

Simply because I'm unaware of this RFC. I have to go though this.

> * experience in hypertext has clearly shown that adding metadate in
> the link is brittle because, when the target changes, there is no way
> to list all links pointing to it, and therefore to modify them (if I
> remember correctly, this was one of the reasons Tim Berners-Lee's
> original article about the Web was rejected, since the craze at this
> time was bidirectional links). This is specially critical here since
> "rights on content" are quite changeable.

It's the responsibility of the publisher to offer URLs which are stable.
Usually they provide URLs with unique IDs and attribute them with SEO terms,
which are ignored at the server side. If they remove content, the URL is
invalid. Usually all content has a short to medium lifetime. So there is no
need to overengineer the protocol at this point.

> * TCP options cannot be relied on
> <https://www.imperialviolet.org/binary/ecntest.pdf>

True. Please let me answer this consideration by responing to the intend of
the draft ...

> Politically, well, to tell the truth, I wondered for a while if it was
> intended to be a 1st april RFC. But I'm ready to hear arguments.
> 
> I'm specially worried about the "compensation" for transit
> providers. They are alreday paid by their clients.

ISPs, especially access/broadband providers try to violate the net
neutrality in order to participate from successful overlay services. News
cooperations and other commercial content providers request a substantial
part of the money gained by the large search engines and aggregator sites.
Both try hard to change the structure of the Internet so, that they can get
money for nothing. During the last few years the political lobbying brought
us several very bad developments, because they told the politicans, no other
ways exist to reach their goals. (I participated in such processes in the
German parliament.)

So the idea of this draft is to provide a reasonable framework to allow
them to reach, what they aim for. In real politics it's a very strong
argument to offer a defined way instead of defending a reinterpretation
(misuse) of an existing mechanism.

I hope, that the EU parliament will change the Voss proposal in September to
use the RIGHT element for this purpose.

It's not my problem to implement and universally roll out this system. But
I'm really interested in helping to implement the TCP option part. Having
real world implementation i.e. in FreeBSD and Linux makes net neutrality
much stronger (If you want to get payed for higher QoS traffic, use the
option.)

Did I make my point clear?

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 19 Aug 2018 12:50:22 -0400

Hi,

> I think someone ought to take what is above and send it as an actual

I have read draft-donnerhacke-linktax-01.  I have some comments.

I believe I understand what the draft wants to do.  Unfortunately, I
think it attempts to do this by tackling the problem at two layers,
such that the mechanism probably won't work.  Moreover, I think it
contains some assumptions about Internet routing that are at least
problematic and that might be described as "not even wrong".  In any
case, the draft proposes an experiment, but it is not clear what the
success criteria would be and it is not clear when the conditions for
possible evidence could be met.

I will start with the issues about routing, take up the layer
violation, and then discuss some other issues I observe in the draft.

1.  Routing

§3.1 contains a caricature of Internet routing that might lead
the naïve reader to imagine a much more orderly routing system for
datagrams than is in fact the norm, and it appears to suggest that
"carriers" are some kind of fundamental unit in routing.  Probably the
author does not intend to make such a statement, but that appears to
me to be the implication.

This caricature appears to be motivated by the goal that appears in
§3.2, which is "to track the route of carriers involved".  It becomes
clear in that section, however, that the mechanism in fact tracks the
ASNs involved in the routing of a given TCP flow: "If the carrier
adds an offer to the list, it MUST keep the routing decision stable
and always route the following packets of this flow to the same ASN as
the initial packet."  As a practical matter, then, this represents a
fundamental change to the basic model of routing on the Internet.
While today routes are mostly stable most of the time, this mechanism
proposes to guarantee that the routes will remain stable.  One of the
features of route changes on the Internet today, however, is that when
the changes happen they often happen in a big way.  The flexibility
that is implicit in those changes is part of what makes us able to
make a mostly reliable network out of unreliable parts.  It is
therefore very far from obvious to me that the trade-off implied here
is a good one: AS operators will gain some revenue, but at the
possible cost of decreased reliability of the network.  And indeed,
the draft is just silent on what an AS does if the route it has
selected goes away.

Therefore, it is hard for me to see how this part of the experiment
can be conducted successfully at Internet scale.  This mechanism will
probably work in a controlled environment where the parts are under
some kind of common control, but to know whether the experiment is
successful the mechanism would have to be deployed very widely.  The
incentives for that appear to be at least weak.  And this does not
even address the problem that TCP options don't appear to work anyway
(as Stephane has pointed out).

2.  Layers

In order for this experiment to work, it is not enough for ASes to
change their routing decisions.  It is also necessary for browsers to
be able to set the necessary TCP option when processing the new
(<RIGHT>) element.  But of course, browsers don't actually have a TCP
stack of their own: they use the ones provided by the operating
system.  So, there are two ways to arrange things such that this
experiment can proceed on the Internet:

    1.  A substantial portion of the operating system libraries get
    updated so that applications can request this option, and browsers
    get updated so that they begin to implement this processing.

    2.  Browsers decide to go around the system TCP/IP stack and just
    implement the feature themselves.

(1) seems like a fairly heavy lift to achieve, in order to perform an
experiment that might not work anyway due to the issues around
routing.  (2) is not only wildly improbable; it is also an extremely
bad idea.  But in any case, this is the classic problem with
innovation at the "waist" of the Internet: it's a delicate place to be
working, and it's extraordinarily difficult to achieve because of the
deployment path before a protocol provides any value.  This is part of
why incremental deployability is identified by the IAB in RFC 5218 as
so important to protocol success.  The proposal in the draft does not
appear to be incrementally deployable: before it provides any value to
anyone, a large number of clients need to be able to use it and a
large number of AS operators need to support it in their routers.
Anything that is dependent on simultaneous changes to two different
layers of the network appears to face a nearly insurmountable barrier
to adoption, so it would need to be providing something of spectacular
value to all the users in order to achieve anything like critical
mass.

3.  Other issues

The draft is unfortunately marred by an overtly political cast to its
framing of the issues.  There is no reason terms could not be
described more neutrally, and the draft would be improved by framing
matters that way.  Indeed, the description of links in §1 is, in my
opinion, completely absurd.  There are _lots of_ hyperlinks on the
Internet that do not work for just anyone, as even casual experience
will attest; so, it is pretty hard to take seriously a proposal to
defend intellectual property on the Internet by upgrading the global
routing infrastructure plus every connected computer in the universe.

"Net neutrality" in the draft is used somewhat oddly.  The term is
unfortunate anyway, because it is ambiguous: sometimes it has to do
with access-network operator choices and traffic prioritization,
whereas other times it has to do with relations between
carrier-network operators and content providers.  But it is really odd
to see a claim that network neutrality can be preserved through a
mechanism by which content providers can pay to prioritize "their"
packets, since that is one of the very practices that net neutrality
proponents oppose.  In effect, this proposal is undermining one
meaning of network neutrality and calling that "preservation".

As a nit, the draft's use of RFC 2119 terminology is not actually
consistent with RFC 2119, and in some places NOT seems not to have
been capitalized when it should have been.  Also, CAN is not a 2119
word.

The draft aims to create a new HTML element, but it is not clear that
an RFC in any stream is the right way to do that given that change
control for HTML lives in another organization that does not use RFCs.

I think the security considerations section needs to discuss the
attack in which an attacker creates offers implicating some other
operator in the satisfaction of the offer.  It seems that would have
financial implications that could be exploited, and the mechanism by
which that would be foiled is not outlined in the draft (and indeed,
appears to be ruled out of scope).

In general, then, while I think I understand what this draft proposes
to do, I think the proposal is not realistically deployable on the
Internet, and that it probably won't work.  I recommend to the author
to abandon it as a nifty thought that won't go anywhere.  If the
author wishes to continue working on it, however, some account of how
the effort is ever going to get deployed, a story about how one would
evaluate the success of the experiment, a more neutral introduction
and motivation, and considerably more discussion of certain security
issues are all necessary.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]