<?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-00">
   <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>Liquid Intelligent Technologies</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>
      <date month="January" day="19" year="2024" />
      <abstract>
	 <t>   There is a trend towards documents describing protocols that are only
   intended to be used within &quot;limited domains&quot;.  Unfortunately, these
   drafts often do not clearly define how the boundary of the limited
   domain is established and enforced, or require that operators of
   these limited domains //perfectly// implement filters to protect the
   rest of the Internet from these protocols.

   In addition, these protocols sometimes require that networks that are
   outside of (and unaffiliated with) the limited domain explicitly
   implement filters in order to protect their networks if these
   protocols leak outside of the limited domain.

   This document discusses the concepts of &quot;fail-open&quot; versus &quot;fail-
   closed&quot; protocols and limited domains, and provides a mechanism for
   designing limited domain protocols that are safer to deploy.

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