Subject: [xml2rfc] subsection failure

From: Randy Bush <[email-masked]>
Date: Thu, 23 Apr 2020 12:44:34 -0700

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>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 23 Apr 2020 17:31:46 -0400

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:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Apr 2020 14:35:42 -0700

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

yikes!

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 23 Apr 2020 17:47:14 -0400

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

that was my feeling when I figured out i had to think about writing as:

2.

stuff

2.1

    more stuff

2.2

   more stuff

=============

there can be NO stuff of level 2 after the end of level 2.2

....

But I can kind of see it.  In that how can the reader, necessarily see 
that 2.2 above ended and the following text is back to 2?

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Apr 2020 14:49:56 -0700

> that was my feeling when I figured out i had to think about writing as:

does not work when 2 is the introduction, as it is in this case

> that 2.2 above ended and the following text is back to 2?

indentation?  yes, i know.

randy

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 23 Apr 2020 18:04:19 -0400

> does not work when 2 is the introduction, as it is in this case

Change all my 2. to 1. and the same is true.

> indentation?  yes, i know.

We do not indent subsections.  Not our style.   ;)

In fact I have seen subsections 6 deep.  Think about how little space 
would be left for text with the extent of the left white space!

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 Apr 2020 15:06:24 -0700

> would be left for text with the extent of the left white space!

<?rfc subindent="42"?>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 23 Apr 2020 18:09:43 -0400

>> would be left for text with the extent of the left white space!

Put in a proposal.  I suspect it would have to be an addendum to the rfc 
on rfc style....

Hey, all I wanted was to indent a list.  The hack was to put the list 
inside a list of one entry with no bullets.  Sheesh.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Apr 2020 00:41:51 +0200

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

Right.  This is pretty much a universal property of the section/subsection concept.
There is no way in standard typography to tell where a subsection ends without ending the entire section, except by starting another subsection on the same level.

So the (recursive) grammar is essentially:

section = t* section*

Where the t* is the introductory text for this section.

I don't think trying to innovate against centuries of the established practice for this is a useful exercise(*).

Grüße, Carsten

(*) In case of insurmountable urge to do so, you can always write a Python program.

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Apr 2020 18:06:45 -0500

On Thu, Apr 23, 2020 at 06:09:43PM -0400, Robert Moskowitz wrote:
> Put in a proposal.  I suspect it would have to be an addendum to the rfc on
> rfc style....

Maybe 343 days from now.