Re: [xml2rfc] subsection failure

[Robert Moskowitz <[e-mail]>]

My experience is that you cannot have text for a section after a subsection.

It all must go before the subsection or be in its own subsection.

On 4/23/20 3:44 PM, Randy Bush wrote:
> 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>
>
> _______________________________________________
> xml2rfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xml2rfc