<?xml version="1.0" encoding="UTF-8"?>  <!-- This is built from a template for a generic Internet Draft. Suggestions for      improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->  <!-- This can be converted using the Web service at http://xml.resource.org/experimental.html      (which supports the latest, sometimes undocumented and under-tested, features.) -->  <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [   ]>   <?rfc toc="yes"?>            <!-- You want a table of contents --> <?rfc symrefs="yes"?>        <!-- Use symbolic labels for references --> <?rfc sortrefs="yes"?>       <!-- This sorts the references --> <?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft --> <?rfc compact="yes"?>   <!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate --> <rfc ipr="trust200902" docName="draft-bogdanovic-i2rs-acl-model-00" category="info"  >   <front>   <title abbrev="I2RS YANG model">ACL YANG model</title>   <author initials="idb" surname="Bogdanovic" fullname="Dean Bogdanovic">     <organization>Juniper Networks</organization>     <address>       <email>deanb@juniper.net</email>     </address> </author> <author initials="db" surname="Blair" fullname="Dana Blair">   <organization>Cisco Systems</organization>   <address>     <email>dblair@cisco.com</email>   </address> </author> <author initials="ks" surname="Sreenivasa" fullname="Kiran Agrahara Sreenivasa">   <organization>Juniper Networks</organization>   <address>     <email>kkoushik@brocade.com</email>   </address> </author>  <date day="24" month="April" year="2014" />  <area>Routing Area</area> <workgroup>I2RS WG</workgroup>  <abstract>   <t>     This document describes information and data model of Access Control List (ACL) basic building blocks.   </t> </abstract> </front>  <middle>   <section anchor="intro" title="Introduction">     <t>       Access Control List (ACL) is one of the basic  elements to configure device forwarding behavior. It is used in many networking concepts (Policy Based Routing, Firewalls, etc) and as such construct, it is very important that model can be easily reused between vendors and between different applications.     </t>   </section> <!-- intro -->    <section anchor="problem" title="Problem Statement">     <t></t>   </section> <!-- problem -->  <section anchor="infomodel" title="ACL Information Model"> <t></t> </section> <!-- infomodel -->  <section anchor="aclmodules" title="ACL Modules"> <t></t>  <section anchor="datamodel" title="ACL Data Model"> <t></t> </section> <!-- datamodel -->  <section anchor="yangmodel" title="ACL YANG Model"> <t></t> </section> <!-- yangmodel -->  </section> <!-- params -->  <section anchor="security" title="Security Considerations"> <t></t> </section> <!-- security -->  <section anchor="iana" title="IANA Considerations"> <t>This document requests no action by IANA. </t> </section> <!-- iana -->  <section anchor="ack" title="Acknowledgements"> <t></t> </section> <!-- ack -->  <section anchor ="changes" title="Change log [RFC Editor: Please remove]"> <t></t> </section> <!-- changes -->  </middle>  <back>  <references title="References"> <?rfc include='reference.RFC.6020'?>  </references>  </back> </rfc>