Scoping Protocols for the Internet

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 http://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 March 26, 2018.

Copyright © 2017 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 (http://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.

[RFC3935] declares that the goal of the IETF “is to make the Internet work better.”

• A large, heterogeneous collection of interconnected systems that can be used for communication of many different types between any interested parties connected to it. The term includes both the “core Internet” (ISP networks) and “edge Internet” (corporate and private networks, often connected via firewalls, NAT boxes, application layer gateways and similar devices.

• In attempting to resolve the question of the IETF’s scope, perhaps the fairest balance is struck by this formulation: “protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet.”

When a new proposal is brought to the IETF, this scope is important to keep in mind; if the proposal is specified to certain kinds of deployments, but might cause harm in others, it could be inappropriate to “have wide deployment and interoperation on the Internet” as a whole.

For example, a datacentre network might want to change how congestion control operates (or remove it entirely) inside its confines. While this might be advantageous in a controlled environment, it would be disastrous to do so on the open Internet, as it would result in congestion collapse [I-D.ietf-tcpm-dctcp].

Or, a financial institution might need to conform to regulations specific to them, and thus need to change how encrypted protocols on their network operate to enable efficient monitoring of activity, while still adhering to their security requirements. While this might be seen as pragmatic in that environment, using such techniques on the open Internet would be widely seen as a step (or many steps) backwards in security, as it would sacrifice forward security, and furthermore be prone to abuse for attacks such as pervasive monitoring [RFC7258].

In discussing such proposals, there is often a question of whether it is appropriate to promote something to Internet Standard, or even publish it at all.

Clearly, every Internet specification need not be deployable on every Internet-connected network; likewise, the very possibility of harm does not automatically preclude standardisation. However, when the potential consequences and/or likelihood of deployment outside the intended environment are too great, such a proposal needs much more careful vetting.

This document explores the properties of such “limited scope” proposals and suggests guidelines for evaluating whether they should be published.

Engineers often concentrate on the problems immediately in front of them, and propose solutions that minimally solve those problems. While this is acceptable practice in a limited, known environment, this style of engineering often fails when proposing changes to the Internet, because it is such a diverse environment.

In a limited environment, it’s not uncommon to be able to make a variety of assumptions about deployment architecture, user expectations, traffic characteristics, and so on. On the Internet as a whole, this is not true; not only is it diverse, but it is also open; we do not know all of the ways in which is is used, deployed, or operated.

Therefore, proposals to change it need to consider what effect they will have when deployed generally, not just specifically within the scope they were designed for.

This document has no actions for IANA.

TBD