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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
