[xml2rfc] subsection failure

[Randy Bush <[e-mail]>]

why does including a subsection give me

  Error: Unable to validate the XML document: draft-ymbk-sidrops-rpki-rov-timing.xml
   <string>: Line 105: Element section content does not follow the DTD, expecting ((t | figure | texttable | iref)* , section*), got (t section t t t t t t t t )
  make: *** [all] Error 1

if i pull it to a separate section it works.

if i eliminte the paragraphs after the first </section> it works.
binary search elimination got me nothing

  <section anchor="intro" title="Introduction">
    
    <t>
      This document explores, and makes recommendations for, timing of
      Resource Public Key Infrastructure (RPKI) publication of ROV data,
      their propagation, and their use in Relying Parties (RP), caches
      and routers.
    </t>

    <section anchor="struct" title="Deployment Structure">
      <t>
	The RPKI supply chain from CAs to reach routers has a structure
	as follows:
      </t>
      <t>
	<list style="hanging">

	  <t hangText="Cerification Authorities:">
	    The authoritative data of the RPKI are published by a
	    distributed set of servers, Certification Authorities, at the
	    IANA, RIRs, NIRs, and ISPs (see <xref target="RFC6481"/>).
	  </t>

	  <t hangText="Publication Points:">
	    The CAs publish their authoritative data in publicly
	    accessible repositories which have a  Publication Point (PP)
	    for each CA.
	  </t>

	   <t hangText="Relying Parties:">
	     Relying Parties are a local set of one or more collected and
	     verified caches of RPKI data which are collected from the PPs.
	   </t>
	   <t>
	     Note that RPs can pull from other RPs, thereby creating a
	     somewhat complex topology.
	   </t>

	   <t hangText="Routers:">
	     Validating routers fetch data from local caches using the RPKI
	     to Router Protocol, <xref target="I-D.ietf-sidrops-8210bis"/>.
	     Routers are clients of the caches.  Validating routers MUST
	     have a trust relationship with, and a trusted transport
	     channel to, any RP(s) they use.  <xref
	     target="I-D.ietf-sidrops-8210bis"/> specifies mechanisms for
	     the router to assure itself of the authenticity of the cache
	     and to authenticate itself to the cache.
	   </t>
	</list>
      </t>
    </section>

    <t>
      As Resource Public Key Infrastructure (RPKI) based Route Origin
      Validation (ROV) becomes deployed in the Internet, the quality of
      the routing control plane, and hence timely and accurate delivery
      of packets in the data plane, depend more and more on prompt and
      accurate propagation of the RPKI data from the originating
      Certification Authorities (CAs), to Relying Parties (RPs), to
      Border Gateway Protocol (BGP) speaking routers.
    </t>

    <t>
      Origin Validation based on stale ROAs allows accidental
      mis-origination.  While delays in ROA propagation to ROV in
      routers can cause loss of good traffic.  Therefore minimizing
      propagation time of data from CAs to routers is critical.
    </t>

    <t>
      Before the data can start on the CA to router chain, the resource
      holder (operator) MUST create or delete the relevant ROA(s)
      through the CA's operational interface(s).  The operator is
      responsible for anticipating their future needs for ROAs, be aware
      of the propagation time from creating ROAs to effect on routing,
      and SHOULD create, delete, or modify ROAs sufficiently in advance
      of any needs in the routing system.
    </t>
    
    <t>
      There are questions of how frequently a CA publishes, how often an
      RP pulls, and how often routers pull from their RP(s).  Overall,
      the router(s) SHOULD react within an hour of ROA publication.
    </t>

    <t>
      For CAs publishing to PPs, a few seconds to a minute seems easily
      achieved with reasonable software.  See <xref target="publish"/>.
    </t>

    <t>
      Relying Party validating caches periodically retrieve data from CA
      publication points.  RPs using rsync to poll publication points
      every ten minutes would be a burden today, given the load it would
      put on publication services, cf. one notorious repository which is
      structured against specification.  RPs using RRDP impose no such
      load.  As the infrastructure moves from rsync to RRDP, fetching
      every ten minutes would be reasonable.  For rsync, an hour would
      be the longest acceptable window.  See <xref target="rp-pull"/>.
    </t>

    <t>
      For the BGP speaking router(s) pulling from the RP(s), five
      minutes to an hour is a wide window.  But, the RPKI-Rtr protocol
      does have the Serial Notify PDU, the equivalent of DNS Notify,
      where the cache tells the router that it has new data.  See <xref
      target="router-pull"/>.
    </t>

    <t>
      We discuss each of these in detail below.
    </t>

  </section>