[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                           L. Donnerhacke
Internet-Draft                                                Fitug e.V.
Intended status: Experimental                              June 21, 2018
Expires: December 23, 2018


                     Rights for restricted content
                      draft-donnerhacke-linktax-00

Abstract

   Links are omnipresent in the Internet to provide access to other
   resources.  There is no mechanism to express differences in law
   systems, access limitations, or arbitrary rules defined by the owner
   of the linked resource.  Therefore links do depend on and enforce a
   communist sharing ideology, which ignores the content owner rights.

   Links may point to resources far away from the originating page,
   hiding this fact from the customer.  It takes the data transport
   services for free, internet transit providers on the way from the
   content source to the customers are not extra payed for this effort.
   In many cases, the remote company generates huge amount of money from
   the customers worldwide not shared with the transit providers.

   In order to get the rights of all involved parties balanced, a new
   type of connection initiation is proposed: The Right.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 23, 2018.








Donnerhacke             Expires December 23, 2018               [Page 1]


Internet-Draft        Rights for restricted content            June 2018


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Referencing restricted content  . . . . . . . . . . . . . . .   4
     2.1.  The RIGHT element . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Monetarization  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Handling Digital Rights Management  . . . . . . . . . . .   4
   3.  Compensate transit providers  . . . . . . . . . . . . . . . .   5
     3.1.  Routing Considerations  . . . . . . . . . . . . . . . . .   5
     3.2.  Option Format . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Offering services . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Accepting offers  . . . . . . . . . . . . . . . . . . . .   6
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The current Internet is best described by the famous quote "From each
   according to his ability, to each according to his needs" by Karl
   Marx [11].  In the Internet everybody provides its resources for the
   use by anybody else.  This is the basic concept behind the hyperlink.
   For the purpose of this memo the concept is called "Left-Wing".

   On the other hand the concept of intellectual property requires to
   have a contractual relationship before use of the requested resource.
   In order to fulfil the needs of the intellectual property industry,



Donnerhacke             Expires December 23, 2018               [Page 2]


Internet-Draft        Rights for restricted content            June 2018


   additional elements needs to be implemented in the Internet.  For the
   purpose of this memo the concept is called "Right-Wing".

   Using the mechanisms defined in this memo, content owners can decide
   the model of access to their property.  They are free to choose new
   mechanisms and monetarize their content, or to keep in line with open
   and free Internet by using the old mechanisms.

1.1.  Background

   The idea of a link tax is commonly attributed to the German publisher
   "Axel Springer".  They claim that "Links" can't be free and that the
   Internet is a "Rechts-freier Raum" (lawless space).  To overcome this
   situation, they invented the "Leistungsschutzrecht", which in turn is
   the founding of the EU proposal [9].

   Implementing this memo will satisfy all those "Right-Wing" claims:

      The new element is called "right" ("rechts" in German), so
      Internet is no longer a "Rechts-freier Raum".

      They can choose to monetarize their content by using the "right"
      instead of the "link" element.  If they are using "link", they
      agree to not sue anybody over the use of the resource.

      If they choose "right", they can limit the amount of usage of the
      reference.  This way the can obtain money from the reverencing
      page (i.e. a news aggregator).

      If they choose "right", they even can limit the usage of the
      content itself.  They can prevent i.e. printing or sharing by the
      customer.

   Furthermore they can speed up their content delivery substantially by
   paying the transit and access providers for a higher level of service
   quality.  This way the net neutrality of the "Left-Wing" needs not to
   be touched.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   memo are to be interpreted as described in RFC 2119 [8].








Donnerhacke             Expires December 23, 2018               [Page 3]


Internet-Draft        Rights for restricted content            June 2018


2.  Referencing restricted content

   References to remote content are done by "links" in the "Left-Wing"
   universe.  The only relevant environment for links for the purposes
   of this memo is the World Wide Web. There the "link" is represented
   by the <LINK> element [6] or the <A> element [7].

2.1.  The RIGHT element

   The new <RIGHT> element is a modification of the existing <LINK>
   element [6].  It differs from the former by the retrieval method used
   by the client browser, and two additional attributes.

   When accessing the referenced resource of the RIGHT element, the
   browser MUST initiate the connection using the TCP options described
   in Section 3.

2.2.  Monetarization

   The RIGHT element MAY have an attribute named "tax", which contains
   an opaque token.  The token SHOULD be a Base64 string [3].  The
   attribute MUST not processed, if the token does exceed the Base64
   charset.  It MAY even check, if the token is really a Base64
   encoding.

   Any valid token MUST be copied to a new HTTP header line "Right:
   tax=token" when requesting the referenced resource.  If the attribute
   does not exist or is invalid, the line SHOULD be omitted.

   The resource provider MAY use this token to validate, that the
   resource was legally requested.  If the token is invalid, it MAY
   respond with the error code 402.  It MUST NOT respond with error code
   451 [5].

   The resource provider MUST provide an API, where new tokens can be
   obtained.  Access to the API SHOULD be limited to paying contractors
   and SHOULD offer tokens which are valid for a larger amount of
   requests and MAY time out.

2.3.  Handling Digital Rights Management

   The RIGHT element MAY have an attribute named "drm", which contains
   an opaque token.  The token SHOULD be a Base64 string [3].  The
   attribute MUST not processed, if the token does exceed the Base64
   charset.  It MAY even check, if the token is really a Base64
   encoding.





Donnerhacke             Expires December 23, 2018               [Page 4]


Internet-Draft        Rights for restricted content            June 2018


   Any valid token MUST be handed over to the local DRM software used to
   process the content of the resource.  The details of the API and the
   processing inside the DRM software is out of the scope of this memo.

3.  Compensate transit providers

3.1.  Routing Considerations

   Traffic from the resource provider to the client (and back) travels
   through the Internet by passing from one internet carrier to the next
   one until it reaches the destination.  The internet carriers are
   interconnected by each other through dedicated peerings.  At such a
   peering, the networks of the carriers talk directly to each other.
   The network of a carrier itself are summarized by an Autonomous
   System Number [2].

   There is no guarantee, that the packets travel the same way all the
   time.  Traffic in one direction may touch completely different
   providers, than on the way back.  The traffic can be rerouted if
   necessary, even if the TCP session is still up.  So it is difficult
   to compensate the involved carriers, simply because they may change
   at any time.

3.2.  Option Format

   In order to track the route of carriers involved, a new TCP option is
   defined.  It contains an arbitrary amount of 32bit ASN / Payload
   pairs.

    0          1          2          3
    01234567 89012345 67890123 45678901
   +--------+--------+--------+--------+
   |  Kind  | Length |       ExID      |
   +--------+--------+--------+--------+
   |  ASN-1                            |
   +--------+--------+--------+--------+
   |  Payload-1                        |
   +--------+--------+--------+--------+
   ...
   |  ASN-n                            |
   +--------+--------+--------+--------+
   |  Payload-n                        |
   +--------+--------+--------+--------+

              Figure 1: Autonomous System Compensation Option

   Kind:     The option kind value is 253.




Donnerhacke             Expires December 23, 2018               [Page 5]


Internet-Draft        Rights for restricted content            June 2018


   Length:   The length of the option is variable, based on the required
             size of the content.  The size will be a multiple of 4.

   ExID:     The experiment ID value is 0x0a0d (2573).

   ASN:      32bit value of the Autonomous System Number.

   Payload:  A 32bit opaque value.

3.3.  Offering services

   In order request a resource according to Section 2.1, the clients
   opens a new TCP connection with the SYN flag set and the ACK flag
   cleared [1] and adds an empty ASN option as defined in Section 3.2.

   Any ASN MAY offer a special service to the content provider by
   appending its own ASN to the end.  The payload contains a
   contractually defined value, i.e. a challenge with nonce bits, which
   will be processed by the content provider.  The list of offers MUST
   NOT be deleted or reordered.

   If there is no contract between the carrier and the content provider,
   the special payload "0" CAN be used.  This means, that the carrier
   want to negotiate a contract.  If those negotiation fails after a
   reasonable period of time, the carrier MAY drop such packets.  In
   this case, it MUST respond with a appropriate, rate-limited ICMP
   error message.

   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.  Furthermore it MUST route all
   the response packets of this flow to the ASN which was last one in
   the list.

3.4.  Accepting offers

   Any new connection containing this ASN option, MUST be signalled to
   the application level.  Processing of the "tax" attribute as defined
   in Section 2.2 MUST be suppressed unless the application got this
   signal.  This way normal "links" are processed as usual, while
   "rights" can be handled correctly.

   On receiving the initial packet at the final destination, the option
   values are examined.  For each OFFER the payload MUST be replaced by
   the contractually defined, computed response.  The list MUST NOT be
   reordered.  If an offer is rejected, the payload is set to "0".  So
   the TCP syn/ack packet contains a ASN option with all the acceptance
   values.



Donnerhacke             Expires December 23, 2018               [Page 6]


Internet-Draft        Rights for restricted content            June 2018


   On the way back each ASN, which put in an offer, examines the option,
   it MUST remove the last item from the ASN option list, if AS number
   matches.  Depending on the response to the offer, the TCP flow SHOULD
   be handled accordingly to the contractual requirements.

   The carrier has to route according to the stored flow context, but
   there are any problems, it SHOULD route toward the last ASN in the
   option.

4.  Acknowledgements

   This memo is influenced by the legislative process in the EU [9].
   Special thanks go to Julia Reda [10] for keeping the public updated.

5.  IANA Considerations

   This memo adds an TCP ExID into the IANA registry
   <https://www.iana.org/assignments/tcp-parameters/tcp-
   parameters.xhtml#tcp-exids> according the the rules of RFC 6994 [4].

                +--------+--------------------------------+
                | Value  | Description                    |
                +--------+--------------------------------+
                | 0x0a0d | Autonomous System Compensation |
                +--------+--------------------------------+

6.  Security Considerations

7.  References

7.1.  Normative References

   [1]        Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [2]        Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [3]        Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [4]        Touch, J., "Shared Use of Experimental TCP Options",
              RFC 6994, DOI 10.17487/RFC6994, August 2013,
              <https://www.rfc-editor.org/info/rfc6994>.



Donnerhacke             Expires December 23, 2018               [Page 7]


Internet-Draft        Rights for restricted content            June 2018


   [5]        Bray, T., "An HTTP Status Code to Report Legal Obstacles",
              RFC 7725, DOI 10.17487/RFC7725, February 2016,
              <https://www.rfc-editor.org/info/rfc7725>.

   [6]        World Wide Web Consortium, "The link element", 2018,
              <https://w3c.github.io/html/
              document-metadata.html#the-link-element>.

   [7]        World Wide Web Consortium, "The a element", 2018,
              <https://w3c.github.io/html/
              textlevel-semantics.html#the-a-element>.

7.2.  Informative References

   [8]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [9]        EUROPEAN COMMISSION, "Proposal for a DIRECTIVE OF THE
              EUROPEAN PARLIAMENT AND OF THE COUNCIL on copyright in the
              Digital Single Market", 2016, <https://eur-lex.europa.eu/
              legal-content/EN/TXT/?uri=CELEX:52016PC0593>.

   [10]       Reda, J., "Homepage", <https://juliareda.eu/>.

   [11]       Marx, K., "Kritik des Gothaer Programms", 1875.

Author's Address

   Lutz Donnerhacke
   Fitug e.V.
   Leutragraben 1
   Jena  07743
   DE

   Phone: +49 3641 573561
   Email: lutz@fitug.de













Donnerhacke             Expires December 23, 2018               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/