I'm replying separately to separate this from the explanation. Quotes from the RFC: > We conclude that it is reasonable to explicitly define limited-domain pr

I'm replying separately to separate this from the explanation. Quotes from the RFC: > We conclude that it is reasonable to explicitly define limited-domain protocols, either as standards or as proprietary mechanisms, as long as they [..] clarify how the domain is defined. [...] However, [new] mechanisms are needed to support domain membership operations. > Note that this conclusion is not a recommendation to abandon the normal goal that a standardized protocol should be global in scope and able to interoperate across the open Internet. It is simply a recognition that this will not always be the case. ----- A few example use-cases that spring to my mind: in a given IoT network, every sensor could conceivably send unencrypted data if the threat model allows it. In a home network, more information could be exchanged between devices, while not being published on the internet: static addresses, device owner, location... This allows scoping the protocols, to tailor security to a threat model in a given environment, for instance, or to specific bandwidth/topology requirements. (incidentally, I find that "scope" is a way better name than "domain". I think that's a comment I'm going to send, this is an RFC after all).