<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.wkumari-intarea-safe-limited-domains" target="https://datatracker.ietf.org/doc/html/draft-wkumari-intarea-safe-limited-domains-05">
   <front>
      <title>Safe(r) Limited Domains</title>
      <author initials="W." surname="Kumari" fullname="Warren Kumari">
         <organization>Google, LLC</organization>
      </author>
      <author initials="A." surname="Alston" fullname="Andrew Alston">
         <organization>Alston Networks</organization>
      </author>
      <author initials="E." surname="Vyncke" fullname="Éric Vyncke">
         <organization>Cisco</organization>
      </author>
      <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
         <organization>Cisco</organization>
      </author>
      <author initials="D. E." surname="Eastlake" fullname="Donald E. Eastlake 3rd">
         <organization>Independent</organization>
      </author>
      <date month="September" day="4" year="2025" />
      <abstract>
	 <t>   Documents describing protocols that are only intended to be used
   within &quot;limited domains&quot; often do not clearly define how the boundary
   of the limited domain is implemented and enforced, or require that
   operators of these limited domains perfectly filter at all of the
   boundary nodes of the domain to protect the rest of the global
   Internet from these protocols and vice-versa.

   This document discusses some design principles and offers mechanisms
   to allow protocols that are designed to operate in a limited domain
   &quot;fail-closed&quot; rather than &quot;fail-open&quot;, thereby making these protocols
   safer to deploy on the Internet.

   These mechanism are not applicable to all protocols intended for use
   in a limited domain, but if implemented on certain classes of
   protocols, they can significantly reduce the risks.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-wkumari-intarea-safe-limited-domains-05" />
   
</reference>
