myth: IETF cannot tell people how to run their networks

[Keith Moore <moore@cs.utk.edu>]

Tony keeps making statements like the one in the subject line of this 
message.  This message attempts to explain why such statements are not 
helpful generalizations.

IETF can, does, and should make various kinds of statements about how 
people run IP networks.  Most of the time, these take the form of 
constraints on how particular protocols operate, that are encoded in 
protocol specifications and are expected to be enforced by 
implementations of these protocols.  Sometimes, they take the form of 
operational rules, such as rules for assignment of IP addresses to 
hosts.  Neither kind of statement is inherently out-of-scope for IETF.

Among the kinds of statements that are appropriate for IETF to make are:

a. Rules that are necessary to ensure the reliable operation of your 
network, or reliable interoperation between your network and other 
networks.

We can't stop you from breaking these rules, but we can say that the 
reliable operation of your network, or interoperation between your 
network and other networks, cannot be assured if you break those rules. 
 In some cases, failure to adhere to these rules may result in your 
peers or access providers discontinuing that access.

b. Rules that are necessary to ensure reliable interoperation of 
applications over your network, or between your network and other 
networks.

We can't stop you from breaking these rules, but we can say that 
adherence to these rules is necessary to provide the services that 
applications rely on, and that Internet applications are designed and 
built on the assumption that these rules are followed.  Some 
applications are more sensitive to disruption of these rules than 
others, and some rules have more of an effect than others.  In some 
cases your traffic may be filtered and/or ignored by potential peers if 
you fail to adhere to application protocols.

c. Rules that are necessary to ensure future extensibility of network 
functionality, say to support self-configuring networks, mobile 
networks, automatic renumbering, increased security, etc.

We can't stop you from breaking these rules, but if you do break these 
rules you may find it difficult to support the new functionality once 
it is defined, and you may find that hosts and/or apps fail to 
interoperate over your network when those hosts and/or apps begin to 
support the new functionality.

d. Rules that are necessary to prevent harm or abuse, by or from your 
network or hosts to the rest of the network, or to preserve the public 
network's ability to support new kinds of applications.

We can't stop you from breaking these rules.  However in some cases 
where your network is actively observed to be harming others' networks 
(like supporting DoS attacks, spam relaying, or transmitting viruses) 
then this may be cause for your network's external access to be 
terminated by your peers or access providers.   And if networks 
(individually or collectively) degrade the internet's ability to 
support new applications then everyone gets less utility out of the 
network.

--

These categories are not mutually-exclusive; a rule may fall into one 
or more of the above categories.  There may exist valid reasons for 
imposing a rule other than those in the list above.

We may discourage the breaking of these rules by various means, 
including writing specifications for protocols that fail to 
operate/interoperate when one or more of those rules are broken, and/or 
by making detection of such rule violations mandatory-to-implement 
parts of standard specifications.  Our goal in doing so is to preserve 
essential functionality and extensibility of the network and to 
increase flexibility rather than to limit it.

Many people feel that it is appropriate to break one or more rules and 
accept corresponding limitations in operation of networks, hosts, or 
applications.  In some cases, particularly for small networks intended 
to support a very limited set of services or applications, such changes 
may be defensible.  However the designs of various aspects of the 
Internet core protocols, and the interactions between those protocols 
and applications, are widely varied and often quite subtle.  Within 
IETF, it has been frequently observed that detailed analysis and/or 
many different kinds of expertise are required to understand these 
interactions and the implications of changes to design assumptions.  It 
might be relatively easy for a network administrator to understand the 
effect of bending a rule for a network that supports, say, only a 
cluster of HTTP servers; it is much more difficult to understand the 
effect of bending a rule for a network that supports a diverse or 
sizable user community - particularly so since protocols change over 
time.  Also, there may be a desire to support new protocols that are 
more affected by the rule-bending than those supported earlier.

--

On the other hand, there are certain kinds of rules that IETF does not 
feel free to make.  For example:

a. We do not insist that you configure your network to admit or pass 
any particular kind of traffic from external networks, other than the 
traffic (e.g. routing protocols) necessary to facilitate such external 
connection as you choose to make.

b. We do not tell you what protocols you must run on your hosts that 
you connect to the network, except for those protocols that are 
necessary to provide network connectivity itself (e.g. neighbor 
discovery).  However some applications cannot tolerate arbitrary 
restrictions on connectivity between participating hosts; if you choose 
to run those applications you may need to make sure that  the 
participating hosts on your network can communicate with other hosts 
participating in that application.

c.  We will not insist that you subject your host or network to 
security threats beyond those inherent in supporting the protocols or 
services that you choose to support.

(there are probably more of these that we've implicitly adhered to but 
which I haven't thought of yet)

----
well, this started off as a quick one-off and ended up looking a lot 
like a draft document.  I'll probably turn it into an I-D in a few 
days.  Anyway, I hope that it facilitates more enlightening discussion 
than the "can't make rules about other people's networks!" "can too!" 
"can not!" "can too!" exchange.

comments welcome.

Keith


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------